Skip site navigation (1) Skip section navigation (2)

Re: Log levels for checkpoint/bgwriter monitoring

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Log levels for checkpoint/bgwriter monitoring
Date: 2007-03-07 05:11:38
Message-ID: 20070307131820.5E23.ITAGAKI.TAKAHIRO@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Smith <gsmith(at)gregsmith(dot)com> wrote:

> After a few months of staring at this data, I've found averages like that 
> misleading.  The real problem areas correlate with the peak pages written 
> at any one checkpoint.  Lowering that value is really the end-game for 
> optimizing the background writer, and the peaks are what will nail you 
> with a nasty fsync pause at checkpoint time.

If you've already had some technical knowledge to lead best settings from
activity logs, could you write it down in the codes? I hope some kinds of
automatic control features in bgwriter if its best configurations vary by
usages or activities.


BTW, I'm planning two changes in bgwriter.

  [Load distributed checkpoint]
    http://archives.postgresql.org/pgsql-patches/2007-02/msg00522.php
  [Automatic adjustment of bgwriter_lru_maxpages]
    http://archives.postgresql.org/pgsql-patches/2007-03/msg00092.php

I have some results that if we have plenty of time for checkpoints,
bgwriter_all_maxpages is not a so important parameter because it is
adjusted to "shared_buffers / duration of checkpoint".
Also, my recommended bgwriter_lru_maxpages is "average number of
recycled buffers per cycle", that is hardly able to tune manually.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center



In response to

Responses

pgsql-hackers by date

Next:From: NikhilSDate: 2007-03-07 06:40:39
Subject: Re: Auto creation of Partitions
Previous:From: Tom LaneDate: 2007-03-07 04:34:57
Subject: Re: Aggressive freezing in lazy-vacuum

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group