| From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Load distributed checkpoint |
| Date: | 2006-12-08 05:49:20 |
| Message-ID: | 20061208142419.665B.ITAGAKI.TAKAHIRO@oss.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> We adjusted the background writer configuration and nearly eliminated
> the problem.
>
> bgwriter_all_maxpages | 600
> bgwriter_all_percent | 10
> bgwriter_delay | 200
> bgwriter_lru_maxpages | 200
> bgwriter_lru_percent | 20
>
> Between the xfs caching and the batter backed cache in the RAID
> controller, the disk writes seemed to settle out pretty well.
Yes, higher bgwriter_all_maxpages is better for stability. I also do so
up to now. However, if some processes makes lots of dirty buffers in the
shortest time, ex.VACUUM, bgwriter begins to write many pages and affects
responce time.
We will be able to set bgwriter_all_maxpages to lower value with load
distributed checkpoint. It expands the range of tuning of bgwriter.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2006-12-08 06:47:29 | Re: SQL/PSM implemenation for PostgreSQL (roadmap) |
| Previous Message | Gavin Sherry | 2006-12-08 05:43:03 | Re: Weak passwords and brute force attacks |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2006-12-08 07:13:05 | Re: Load distributed checkpoint |
| Previous Message | ITAGAKI Takahiro | 2006-12-08 05:22:14 | Re: Load distributed checkpoint |