pg.ddx.io pgsql-hackers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: PostgreSQL Win32 port list <pgsql-hackers-win32@postgresql.org>
Subject: Re: [HACKERS] Sync vs. fsync during checkpoint
Date: Thu, 05 Feb 2004 09:54:49 -0500
Message-ID: <2297.1075992889@sss.pgh.pa.us> (raw)
In-Reply-To: <46C15C39FEB2C44BA555E356FBCD6FA49620A3@m0114.s-mxs.net>
References: <46C15C39FEB2C44BA555E356FBCD6FA49620A3@m0114.s-mxs.net>
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.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.
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.
People keep saying that the bgwriter mustn't write pages synchronously
because it'd be bad for performance, but I think that analysis is
faulty. Performance of what --- the bgwriter? Nonsense, the *point*
of the bgwriter is to do the slow tasks. The only argument that has
any merit is that O_SYNC or immediate fsync will prevent us from having
multiple writes outstanding and thus reduce the efficiency of disk
write scheduling. This is a valid point but there is a limit to how
many writes we need to have in flight to keep things flowing smoothly.
What I'm thinking now is that the bgwriter should issue frequent fsyncs
for its writes --- not immediate, but a lot more often than once per
checkpoint. Perhaps take one recently-written unsynced file to fsync
every time it is about to sleep. You could imagine various rules for
deciding which one to sync; perhaps the one with the most writes issued
against it since last sync. When we have tablespaces it'd make sense to
try to distribute the syncs across tablespaces, on the assumption that
the tablespaces are probably on different drives.
regards, tom lane
view thread (31+ messages) latest in thread
Message-ID: <2297.1075992889@sss.pgh.pa.us> Permalink: ../2297.1075992889@sss.pgh.pa.us/ Also on: postgresql.org/message-id/2297.1075992889@sss.pgh.pa.us ·
reply
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Reply to all the recipients using the --to and --cc options: reply via email To: pgsql-hackers@postgresql.org Cc: tgl@sss.pgh.pa.us, ZeugswetterA@spardat.at, pgman@candle.pha.pa.us, pgsql-hackers-win32@postgresql.org Subject: Re: [HACKERS] Sync vs. fsync during checkpoint In-Reply-To: <2297.1075992889@sss.pgh.pa.us> * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox