Re: shared_buffers/effective_cache_size on 96GB server

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.

In response to

Browse pgsql-performance by date

  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