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

Re: [HACKERS] fsync method checking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>,pgsql-performance(at)postgresql(dot)org,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] fsync method checking
Date: 2004-03-18 19:28:07
Message-ID: 11459.1079638087@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> As I recall, that was based on testing on some different platforms.

> But why perfer O_DSYNC over fdatasync if you don't prefer O_SYNC over
> fsync?

It's what tested out as the best bet.  I think we were using pgbench
as the test platform, which as you know I have doubts about, but at
least it is testing one actual write/sync pattern Postgres can generate.
The choice between the open flags and fdatasync/fsync depends a whole
lot on your writing patterns (how much data you tend to write between
fsync points), so I don't have a lot of faith in randomly-chosen test
programs as a guide to what to use for Postgres.

>> What does that mean?  You can't fsync a closed file.

> You reopen and fsync.

Um.  I just looked at that test program, and I think it needs a whole
lot of work yet.

* Some of the test cases count open()/close() overhead, some don't.
  This is bad, especially on platforms like Solaris where open() is
  notoriously expensive.

* You really cannot put any faith in measuring a single write,
  especially on a machine that's not *completely* idle otherwise.
  I'd feel somewhat comfortable if you wrote, say, 1000 8K blocks and
  measured the time for that.  (And you have to think about how far
  apart the fsyncs are in that sequence; you probably want to repeat the
  measurement with several different fsync spacings.)  It would also be
  a good idea to compare writing 1000 successive blocks with rewriting
  the same block 1000 times --- if the latter does not happen roughly
  at the disk RPM rate, then we know the drive is lying and all the
  numbers should be discarded as meaningless.

* The program is claimed to test whether you can write from one process
  and fsync from another, but it does no such thing AFAICS.

BTW, rather than hard-wiring the test file name, why don't you let it be
specified on the command line?  That would make it lots easier for
people to compare the performance of several disk drives, if they have
'em.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Bruce MomjianDate: 2004-03-18 19:55:29
Subject: Re: [HACKERS] fsync method checking
Previous:From: Bruce MomjianDate: 2004-03-18 19:22:10
Subject: Re: [HACKERS] fsync method checking

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-03-18 19:52:07
Subject: Re: syntax error position "CREATE FUNCTION" bug fix
Previous:From: Bruce MomjianDate: 2004-03-18 19:22:10
Subject: Re: [HACKERS] fsync method checking

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