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

Re: [HACKERS] Sync vs. fsync during checkpoint

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: [HACKERS] Sync vs. fsync during checkpoint
Date: 2004-02-06 15:07:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-hackers-win32
Tom Lane wrote:

> "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)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:

> 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.


# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2004-02-06 16:01:09
Subject: Re: Advice regarding configuration parameters
Previous:From: Peter EisentrautDate: 2004-02-06 14:32:06
Subject: Re: Advice regarding configuration parameters

pgsql-hackers-win32 by date

Next:From: Neil ConwayDate: 2004-02-06 21:23:50
Subject: Re: [PATCHES] win32 signals, part 4
Previous:From: Tom LaneDate: 2004-02-05 16:22:00
Subject: Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint

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