Re: Load distributed checkpoint

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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