Jan Wieck wrote:
> Tom Lane wrote:
>
> > "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> >> So Imho the target should be to have not much IO open for the checkpoint,
> >> so the fsync is fast enough, even if serial.
> >
> > The best we can do is push out dirty pages with write() via the bgwriter
> > and hope that the kernel will see fit to write them before checkpoint
> > time arrives. I am not sure if that hope has basis in fact or if it's
> > just wishful thinking. Most likely, if it does have basis in fact it's
> > because there is a standard syncer daemon forcing a sync() every thirty
> > seconds.
>
> Looking at the response time charts I did for showing how vacuum delay
> is doing, it seems at least on Linux there is hope that that is the
> case. Those charts have just a regular 5 minute checkpoint with enough
> checkpoint segments for that, and no other sync effort done at all.
>
> The system has a hard time to handle a larger scaled test DB, so it is
> definitely well saturated with IO. The charts are here:
>
> http://developer.postgresql.org/~wieck/vacuum_cost/
>
> >
> > That means that instead of an I/O storm every checkpoint interval,
> > we get a smaller I/O storm every 30 seconds. Not sure this is a big
> > improvement. Jan already found out that issuing very frequent sync()s
> > isn't a win.
>
> In none of those charts I can see any checkpoint caused IO storm any
> more. Charts I'm currently doing for 7.4.1 show extremely clear spikes
> at checkpoints. If someone is interested in those as well I will put
> them up.
So, Jan, are you basically saying that the background writer has solved
the checkpoint I/O flood problem, and we just need to deal with changing
sync to multiple fsync's at checkpoint?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
