From: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "Ron Mayer" <rm_pg(at)cheapcomplexdevices(dot)com>, "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Load distributed checkpoint |
Date: | 2006-12-12 09:22:05 |
Message-ID: | E1539E0ED7043848906A8FF995BDA5790198ECC8@m0143.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> > One thing I do worry about is if both postgresql and the OS
> > are both delaying write()s in the hopes of collapsing them
> > at the same time. If so, this would cause both to be experience
> > bigger delays than expected, and make checkpoints worse.
>
> That is my concern. Letting 30 seconds worth of dirty pages
accumulate
> between checkpoints and then trying to smooth the writes within
> checkpoint code seems like a doomed effort.
30 seconds ??? You are supposed to avoid excessive checkpoints.
If you are reducing checkpoint_timeout to avoid the spike, you are imho
definitely tuning the wrong knob. You are supposed to increase
checkpoint_timeout as far as you can to still have an acceptable
recovery delay after a crash.
If you cannot afford a huge spike during checkpoint, say every 30
minutes,
you have to make bgwriter more aggressive. This would generally be true
for
both of the variants, db driven direct io and buffered filesystem io.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2006-12-12 10:40:09 | Re: Grouped Index Tuples |
Previous Message | DANTE Alexandra | 2006-12-12 09:17:53 | PostgreSQL 8.2 : regression failures on IA-64 |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2006-12-12 15:03:23 | Re: Load distributed checkpoint |
Previous Message | Kevin Grittner | 2006-12-11 21:58:17 | Re: Load distributed checkpoint |