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: | Raw Message | Whole Thread | 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 |