Re: bgwriter statistics

Поиск
Список
Период
Сортировка
От ITAGAKI Takahiro
Тема Re: bgwriter statistics
Дата
Msg-id 20060605181736.5E56.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
обсуждение исходный текст
Ответ на bgwriter statistics  (Jim Nasby <jnasby@pervasive.com>)
Список pgsql-hackers
On 2006-06-02 21:26, Jim Nasby wrote:

> Now that we've got a nice amount of tuneability in the bgwriter, it
> would be nice if we had as much insight into how it's actually doing.
> I'd like to propose that the following info be added to the stats
> framework to assist in tuning it:

I'm interested in your idea. You want to know what bgwriter does.
Also, I think there is another perspective; what bgwriter *should* do.
I imagine the information that pages are dirty or not is useful for
the purpose.

- dirty_pages:       The number of pages with BM_DIRTY in the buffer pool.
- replaced_dirty:       Total replaced pages with BM_DIRTY.       Backends should write the pages themselves.
- replaced_clean:       Same as above, but without BM_DIRTY.       Backends can replace them freely.

Bgwriter should boost ALL activity if dirty_pages is high,
and boost LRU activity if replaced_dirty is high.
In ideal, the parameters of bgwriter can be tuned almost automatically:

- LRU scans = replaced_dirty + replaced_clean
- LRU writes = replaced_dirty
- ALL scans/writes = the value that can keep dirty_pages low


However, tracking the number of dirty pages is not free. I suppose
the implementation should be well considered to avoid lock contentions.

Comments are welcome.

---
ITAGAKI Takahiro
NTT OSS Center



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: XLOG_BLCKSZ vs. wal_buffers table
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Faster Updates