| From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: bgwriter statistics |
| Date: | 2006-06-05 09:17:45 |
| Message-ID: | 20060605181736.5E56.ITAGAKI.TAKAHIRO@oss.ntt.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2006-06-05 09:28:08 | Re: More thoughts about planner's cost estimates |
| Previous Message | Bruce Momjian | 2006-06-05 03:55:29 | Re: Re [HACKERS]: Still not happy with psql's multiline history behavior |