| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Ondrej Ivanič <ondrej(dot)ivanic(at)gmail(dot)com> |
| Cc: | Julien Cigar <jcigar(at)ulb(dot)ac(dot)be>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: shared_buffers/effective_cache_size on 96GB server |
| Date: | 2012-10-10 22:14:45 |
| Message-ID: | CAGTBQparTWDOjqQQovbR+NyYkPppxR0jYLvWrTv+wxBuKHP_FQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Oct 10, 2012 at 7:06 PM, Ondrej Ivanič <ondrej(dot)ivanic(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2012-10-10 22:33:11 | Re: shared_buffers/effective_cache_size on 96GB server |
| Previous Message | Ondrej Ivanič | 2012-10-10 22:06:09 | Re: shared_buffers/effective_cache_size on 96GB server |