Horton

Re: Spread checkpoint sync

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-12-02T06:11:21Z
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.

On 01.12.2010 23:30, Greg Smith wrote:
> Heikki Linnakangas wrote:
>> Do you have any idea how to autotune the delay between fsyncs?
>
> I'm thinking to start by counting the number of relations that need them
> at the beginning of the checkpoint. Then use the same basic math that
> drives the spread writes, where you assess whether you're on schedule or
> not based on segment/time progress relative to how many have been sync'd
> out of that total. At a high level I think that idea translates over
> almost directly into the existing write spread code. Was hoping for a
> sanity check from you in particular about whether that seems reasonable
> or not before diving into the coding.

Sounds reasonable to me. fsync()s are a lot less uniform than write()s, 
though. If you fsync() a file with one dirty page in it, it's going to 
return very quickly, but a 1GB file will take a while. That could be 
problematic if you have a thousand small files and a couple of big ones, 
as you would want to reserve more time for the big ones. I'm not sure 
what to do about it, maybe it's not a problem in practice.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com