Re: performance tuning: shared_buffers, sort_mem; swap

"Thomas O'Connell" <tfo(at)monsterlabs(dot)com> writes:
> for instance, if i set shared_buffers to 4096, this should mean
> postmaster will require 4096 * 8192 = 33554432 bytes, right? but when i
> start it, i get the error above with a request size of 38371328. what's
> the extra padding from? sort_mem, etc?

No, sort_mem is backend-local.

postgresql.conf lists these parameters as affecting shared memory size:

#
# Shared Memory Size
#
#shared_buffers = 64 # 2*max_connections, min 16
#max_fsm_relations = 100 # min 10, fsm is free space map
#max_fsm_pages = 10000 # min 1000, fsm is free space map
#max_locks_per_transaction = 64 # min 10
#wal_buffers = 8 # min 4

This list misses max_connections which also has nontrivial influence.

The multiplier for shared_buffers is somewhat higher than 8192, because
there's a buffer management block (bufhdr) to allocate as well as the
physical data block. The lock table is sized on the basis of
max_locks_per_transaction * max_connections entries, and there are other
shared data structures that are per-backend so are sized as multiples of
max_connections. I think the multiplier for max_fsm_pages is 6 bytes;
not sure about max_fsm_relations but it's probably a couple dozen bytes
per relation.

There are also a number of fixed-size data structures in shared memory,
and I believe we throw on a 10% fudge factor for good luck after we're
done counting up what we think we need.

You could work out the effective multipliers for these parameters with a
little bit of experimental effort...

regards, tom lane