Horton

Re: Spread checkpoint sync

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-01-17T16:19:20Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add new buffers_backend_fsync field to pg_stat_bgwriter.

Greg Smith wrote:
> One of the components to the write queue is some notion that writes that 
> have been waiting longest should eventually be flushed out.  Linux has 
> this number called dirty_expire_centiseconds which suggests it enforces 
> just that, set to a default of 30 seconds.  This is why some 5-minute 
> interval checkpoints with default parameters, effectively spreading the 
> checkpoint over 2.5 minutes, can work under the current design.  
> Anything you wrote at T+0 to T+2:00 *should* have been written out 
> already when you reach T+2:30 and sync.  Unfortunately, when the system 
> gets busy, there is this "congestion control" logic that basically 
> throws out any guarantee of writes starting shortly after the expiration 
> time.

Should we be writing until 2:30 then sleep 30 seconds and fsync at 3:00?

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +