Re: Disk latency goes up during certaing pediods

From: bricklen <bricklen(at)gmail(dot)com>
To: German Becker <german(dot)becker(at)gmail(dot)com>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Disk latency goes up during certaing pediods
Date: 2013-07-30 16:02:26
Message-ID: CAGrpgQ88BGPiasSvMABw6pOBx56atYY0xJKqBP=jJ1QAJsTX0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Tue, Jul 30, 2013 at 8:35 AM, German Becker <german(dot)becker(at)gmail(dot)com>wrote:

> 256 was set some time when we were testing a differnt issue. I read that
> the only drawback is the amunt of time required for recovery, which was
> tested and it was like 10 seconds for the 256 segments, and higher values
> mean less disk usage.
> Anyway all these parameters should affect the throughput to the data
> disks, not the WAL, Am I right?
>
>
checkpoint_completion_target is to help with "checkpoint smoothing", to
reduce the spike in disk I/O when shared_buffers are written out. Depesz
has a good article about that:
http://www.depesz.com/2010/11/03/checkpoint_completion_target/

Do your graphs show any correlation between number of WAL segments getting
recycled, and disk I/O spikes? Are you logging checkpoints? If so, you
could use the checkpoint times to compare against your I/O graphs. I am by
no means an expert here, I'm just throwing out ideas (which might already
have been suggested).

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message CS DBA 2013-07-30 23:19:48 db crash, streaming rep slave will not start
Previous Message German Becker 2013-07-30 15:35:02 Re: Disk latency goes up during certaing pediods