On Tue, Apr 20, 2010 at 12:07 PM, Jim Nasby <deci...@decibel.org> wrote: > On Apr 16, 2010, at 4:56 PM, Robert Haas wrote: >> From reading this and other threads, I think I generally understand >> that the perils of setting shared_buffers too high: memory is needed >> for other things, like work_mem, a problem which is exacerbated by the >> fact that there is some double buffering going on. Also, if the >> buffer cache gets too large, checkpoints can involve writing out >> enormous amounts of dirty data, which can be bad. > > I've also seen large shared buffer settings perform poorly outside of IO > issues, presumably due to some kind of internal lock > contention. I tried running 8.3 with 24G for a while, but dropped it back > down to our default of 8G after noticing some performance > problems. Unfortunately I don't remember the exact details, let alone having > a repeatable test case. >
i have heard this before, sadly enough i don't have a machine for that kind of tests and can't use my customer's production servers for such things :) so, i always set shared buffers lower than 8Gb even if i have ram for more... someone can confirm the lock contention theory? this should be noticeable at checkpoint time right? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
