Re: performance tuning: shared_buffers, sort_mem; swap
От | Tom Lane |
---|---|
Тема | Re: performance tuning: shared_buffers, sort_mem; swap |
Дата | |
Msg-id | 1372.1029274016@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: performance tuning: shared_buffers, sort_mem; swap (Thomas O'Connell <tfo@monsterlabs.com>) |
Ответы |
Re: performance tuning: shared_buffers, sort_mem; swap
|
Список | pgsql-admin |
"Thomas O'Connell" <tfo@monsterlabs.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
В списке pgsql-admin по дате отправления: