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-09 02:04:58
Message-ID: 20070309104251.6341.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Greg Smith <gsmith(at)gregsmith(dot)com> wrote:

> > Also, my recommended bgwriter_lru_maxpages is "average number of
> > recycled buffers per cycle", that is hardly able to tune manually.
>
> This is completely dependent on what percentage of your buffer cache is
> pinned.

Don't you mean usage_count? In my understanding, each backend pins two
or so buffers at once. So percentage of pinned buffers should be low.

> If your load is something like the standard pgbench, the LRU
> writer will rarely find anything useful to write, so this entire line of
> thinking won't work. The proper behavior for heavily pinned data is to
> turn off the LRU writer altogether so there's more time to run the all
> scan.

I think you are pointing out the problem of buffer management algorithm
itself, not only bgwriter. Even if you turn off the LRU writer, each
backend pays the same cost to find recyclable buffers every time they
allocate a buffer.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-03-09 05:42:41 Re: RFC: changing autovacuum_naptime semantics
Previous Message ITAGAKI Takahiro 2007-03-09 01:42:13 Re: Log levels for checkpoint/bgwriter monitoring