Re: Log levels for checkpoint/bgwriter monitoring - Mailing list pgsql-hackers

From ITAGAKI Takahiro
Subject Re: Log levels for checkpoint/bgwriter monitoring
Date
Msg-id 20070309104251.6341.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Whole thread Raw
In response to Re: Log levels for checkpoint/bgwriter monitoring  (Greg Smith <gsmith@gregsmith.com>)
Responses Re: Log levels for checkpoint/bgwriter monitoring  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
Greg Smith <gsmith@gregsmith.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




pgsql-hackers by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Re: Log levels for checkpoint/bgwriter monitoring
Next
From: Tom Lane
Date:
Subject: Re: RFC: changing autovacuum_naptime semantics