On Sat, Jan 15, 2011 at 5:57 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> I was just giving an example of how I might do an initial split. There's a
> checkpoint happening now at time T; we have a rough idea that it needs to be
> finished before some upcoming time T+D. Currently with default parameters
> this becomes:
>
> Write: 0.5 * D; Sync: 0
>
> Even though Sync obviously doesn't take zero. The slop here is enough that
> it usually works anyway.
>
> I was suggesting that a quick reshuffling to:
>
> Write: 0.4 * D; Sync: 0.4 * D
>
> Might be a good first candidate for how to split the time up better.
What is the basis for thinking that the sync should get the same
amount of time as the writes? That seems pretty arbitrary. Right
now, you're allowing 3 seconds per fsync, which could be a lot more or
a lot less than 40% of the total checkpoint time, but I have a pretty
clear sense of why that's a sensible thing to try: you give the rest
of the system a moment or two to get some I/O done for something other
than the checkpoint before flushing the next batch of buffers. But
the checkpoint activity is always going to be spikey if it does
anything at all, so spacing it out *more* isn't obviously useful.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company