On Thu, Feb 7, 2013 at 7:41 AM, Charles Gomes <charlesrg@outlook.com> wrote:
> I've benchmarked shared_buffers with high and low settings, in a server
> dedicated to postgres with 48GB my settings are:
> shared_buffers = 37GB
> effective_cache_size = 38GB
>
> Having a small number and depending on OS caching is unpredictable, if the
> server is dedicated to postgres you want make sure postgres has the memory.
> A random unrelated process doing a cat /dev/sda1 should not destroy postgres
> buffers.
> I agree your problem is most related to dirty background ration, where
> buffers are READ only and have nothing to do with disk writes.
You make an assertion here but do not tell us of your benchmarking
methods. My testing in the past has show catastrophic performance
with very large % of memory as postgresql buffers with heavy write
loads, especially transactional ones. Many others on this list have
had the same thing happen. Also you supposed PostgreSQL has a better
/ smarter caching algorithm than the OS kernel, and often times this
is NOT the case.
In this particular instance the OP may not be seeing an issue from too
large of a pg buffer, my point still stands, large pg_buffer can cause
problems with heavy or even moderate write loads.
