Skip site navigation (1) Skip section navigation (2)

Re: Spread checkpoint sync

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Spread checkpoint sync
Date: 2011-02-01 18:30:12
Message-ID: 201102011830.p11IUC319445@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas wrote:
> Back to your idea: One problem with trying to bound the unflushed data
> is that it's not clear what the bound should be.  I've had this mental
> model where we want the OS to write out pages to disk, but that's not
> always true, per Greg Smith's recent posts about Linux kernel tuning
> slowing down VACUUM.  A possible advantage of the Momjian algorithm
> (as it's known in the literature) is that we don't actually start
> forcing anything out to disk until we have a reason to do so - namely,
> an impending checkpoint.

My trivial idea was:  let's assume we checkpoint every 10 minutes, and
it takes 5 minutes for us to write the data to the kernel.   If no one
else is writing to those files, we can safely wait maybe 5 more minutes
before issuing the fsync.  If, however, hundreds of writes are coming in
for the same files in those final 5 minutes, we should fsync right away.

My idea is that our delay between writes and fsync should somehow be
controlled by how many writes to the same files are coming to the kernel
while we are considering waiting because the only downside to delay is
the accumulation of non-critical writes coming into the kernel for the
same files we are going to fsync later.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-02-01 18:30:34
Subject: Re: SSI patch version 14
Previous:From: Dimitri FontaineDate: 2011-02-01 18:21:03
Subject: ALTER EXTENSION UPGRADE, v3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group