Tom Lane wrote: > Scott Marlowe <scott.marlowe@xxxxxxxxx> 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@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
