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 по дате отправления: