On Tue, Apr 20, 2010 at 12:07 PM, Jim Nasby <decibel@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
internallock
> contention. I tried running 8.3 with 24G for a while, but dropped it back down to our default of 8G after noticing
someperformance
> 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