Re: Log levels for checkpoint/bgwriter monitoring

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

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