Hi admins,
We are running production PostgreSQL (7.2.3) servers on beefy
systems: 4x Xeon 1.4GHz; and 12GB of RAM.
We are trying to determine optimal settings for
shared_buffers and the other memory-related performance
tunables, to make the best use of our 12GB. But we are not
sure what limits we may hit, so we are trying to take care.
The systems are Redhat Linux 7.3 / 2.4.20-18.7bigmem
Currently our settings are:
/proc/sys/kernel/shmall
536870912
/proc/sys/kernel/shmmax
536870912
postgresql.conf:
shared_buffers = 32768
max_connections = 768
max_fsm_relations = 100 [default]
max_fsm_pages = 10000 [default]
wal_buffers = 32
sort_mem = 2048
vacuum_mem = 32768
wal_files = 32
checkpoint_segments = 10
effective_cache_size = 1000
This currently gives us 256 MB of PG shared buffers, which
still seems way too conservative given the amount of RAM
we have to play with.
Is there a limit on shmall/shmmax and how big we can make
shared_buffers ? Or should we just go ahead and give it
4, 6 or 8 GB of shared memory ?
These servers are already quite busy, are serving multiple
databases on each (one postgresql instance on each) with
.../data/base/ at about 16GB in size currently (growing all
the time).
The kernel happily chews up all available RAM for I/O
buffers, which is nice - but how much RAM is better utilized
by PG shared buffers rather than kernel buffers ?
If it matters, all data storage lives on dedicated Netapps
and is accessed by NFS. This is not a performance issue
(despite what you may think) and is done to provide HA
failover using heartbeat.
Any tuning tips for servers this large would be appreciated.
Cheers
CM
--
Chris Miles
http://chrismiles.info/
