Tom Lane wrote:
> Scott Marlowe <scott.marlowe@gmail.com> writes:
> > The session servers we have at work are a perfect match for this. By
> > increasing checkpoint segments to 100 (or more), timeout to 60
> > minutes, and setting completion target lower (currently 0.25) we have
> > reduced our IO wait from 10 to 15% to nearly nothing. These are
> > databases that update the same rows over and over with session data as
> > the user navigates the system, so writing things out as early as
> > possible is a REAL bad idea.
>
> > I found that lowering checkpoint completion target was what helped.
> > Does that seem counter-intuitive to you?
>
> Once the checkpoint completion target time is high enough that the
> checkpoint-induced I/O is just background noise for you, increasing the
> target further won't make for any noticeable further improvement. I'm
> not sure I see how it would make things *worse* though. Maybe, even
> though the I/O wait is "nearly nothing", the I/O is still forcing enough
> extra seeks to slow normal disk operations? If so, getting the
> checkpoint out of the way sooner so that you can get back to full speed
> operation sooner might be better than reducing the rate of checkpoint
> I/Os below the nearly-noise level. I'm just guessing about that though.
> What were you measuring --- the performance within checkpoint, the
> performance outside it, or the whole-cycle average?
My guess is that having a very long fuzzy checkpoint time means that
when you fsync you are fsync'ing lots of data, both your checkpoint data
and other writes performed by backends.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
