Re: shared_buffers/effective_cache_size on 96GB server - Mailing list pgsql-performance

From Claudio Freire
Subject Re: shared_buffers/effective_cache_size on 96GB server
Date
Msg-id CAGTBQparTWDOjqQQovbR+NyYkPppxR0jYLvWrTv+wxBuKHP_FQ@mail.gmail.com
Whole thread Raw
In response to Re: shared_buffers/effective_cache_size on 96GB server  (Ondrej Ivanič <ondrej.ivanic@gmail.com>)
List pgsql-performance
On Wed, Oct 10, 2012 at 7:06 PM, Ondrej Ivanič <ondrej.ivanic@gmail.com> wrote:
>> Generally going over 4GB for shared_buffers doesn't help.. some of the
>> overhead of bgwriter and checkpoints is more or less linear in the size of
>> shared_buffers ..
>
> Nothing is black or white; It's all shades of Grey :) It depends on
> workload. In my case external consultants recommended 8GB and I was
> able to increase it up to 10GB. This was mostly read-only workload.
> From my experience large buffer cache acts as handbrake for
> write-heavy workloads.

Which makes me ask...

...why can't checkpoint_timeout be set above 1h? Mostly for the
checkpoint target thing.

I know, you'd need an unholy amount of WAL and recovery time, but
modern systems I think can handle that (especially if you don't care
much about recovery time).

I usually set checkpoint_timeout to approach the time between periodic
mass updates, and it works rather nice. Except when those updates are
spaced more than 1h, my hands are tied.


pgsql-performance by date:

Previous
From: Ondrej Ivanič
Date:
Subject: Re: shared_buffers/effective_cache_size on 96GB server
Next
From: Jeff Janes
Date:
Subject: Re: shared_buffers/effective_cache_size on 96GB server