Re: Log levels for checkpoint/bgwriter monitoring

Поиск
Список
Период
Сортировка
От ITAGAKI Takahiro
Тема Re: Log levels for checkpoint/bgwriter monitoring
Дата
Msg-id 20070309101224.633B.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Log levels for checkpoint/bgwriter monitoring  (Jim Nasby <decibel@decibel.org>)
Список 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 по дате отправления:

Предыдущее
От: Galy Lee
Дата:
Сообщение: Re: RFC: changing autovacuum_naptime semantics
Следующее
От: ITAGAKI Takahiro
Дата:
Сообщение: Re: Log levels for checkpoint/bgwriter monitoring