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).
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 |