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 20070309101224.633B.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Whole thread Raw
In response to Re: Log levels for checkpoint/bgwriter monitoring  (Jim Nasby <decibel@decibel.org>)
List pgsql-hackers
Jim Nasby <decibel@decibel.org> wrote:

> > Also, my recommended bgwriter_lru_maxpages is "average number of
> > recycled buffers per cycle", that is hardly able to tune manually.
> 
> What do you mean by 'number of recycled buffers per cycle"?

There is the following description in the documentation:

| * bgwriter_lru_percent (floating point)
| To reduce the probability that server processes will need to issue their
| own writes, the background writer tries to write buffers that are likely
| to be recycled soon.
| * bgwriter_lru_maxpages (integer)
| In each round, no more than this many buffers will be written as a
| result of scanning soon-to-be-recycled buffers.

The number of recycled buffers per round is the same as the number of
StrategyGetBuffer() calls per round. I think the number is suitable for
bgwriter_lru_maxpages if we want bgwriter to write almost of dirty pages.

I proposed to change the semantics of bgwriter_lru_maxpages. It represented
"maximum writes per round", but the new meaning is "reserved buffers for
recycle". Non-dirty unused buffers will be counted among it.


I'm measuring the difference of performance between manual and automatic
tuning, especially adding some jobs before writes. I'll inform you about
them when I get the results.

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




pgsql-hackers by date:

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