From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Checkpoints and slow queries |
Date: | 2014-04-28 20:41:16 |
Message-ID: | 535EBCEC.4000501@fuzzy.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 28.4.2014 16:07, Tom Lane wrote:
> Elanchezhiyan Elango <elanelango(at)gmail(dot)com> writes:
>>> The problem is that while this makes the checkpoints less
>>> frequent, it accumulates more changes that need to be written to
>>> disk during the checkpoint. Which means the impact more severe.
>
>> True. But the checkpoints finish in approximately 5-10 minutes
>> every time (even with checkpoint_completion_target of 0.9).
>
> There's something wrong with that. I wonder whether you need to
> kick checkpoint_segments up some more to keep the checkpoint from
> being run too fast.
>
> Even so, though, a checkpoint spread over 5-10 minutes ought to
> provide the kernel with enough breathing room to flush things. It
> sounds like the kernel is just sitting on the dirty buffers until it
> gets hit with fsyncs, and then it's dumping them as fast as it can.
> So you need some more work on tuning the kernel parameters.
There's certainly something fishy, because although this is the supposed
configuration:
checkpoint_segments = 250
checkpoint_timeout = 1h
checkpoint_completion_target = 0.9
the checkpoint logs typically finish in much shorter periods of time.
Like this, for example:
>
> regards, tom lane
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2014-04-28 20:54:09 | Re: Checkpoints and slow queries |
Previous Message | Karl Denninger | 2014-04-28 18:29:29 | Re: Revisiting disk layout on ZFS systems |