New test_fsync messages for direct I/O

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: New test_fsync messages for direct I/O
Date: 2011-01-16 00:15:04
Message-ID: 201101160015.p0G0F4113329@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus wrote:
> Greg,
>
> > This is interesting, because test_fsync consistently reported a rate of
> > about half this when using open_datasync instead of the equal
> > performance I'm getting from the database. I'll see if I can reproduce
> > that further, but it's no reason to be concerned about the change that's
> > been made I think. Just more evidence that test_fsync has quirks left
> > to be sorted out. But that's not backbranch material, it should be part
> > of 9.1 only refactoring, already in progress via the patch Josh
> > submitted. There's a bit of time left to get that done.
>
> Did you rerun test_sync with O_DIRECT entabled, using my patch? The
> figures you had from test_fsync earlier were without O_DIRECT.

I have modified test_fsync with the attached, applied patch to report
cases where we are testing without O_DIRECT when only O_DIRECT would be
used by the server, and cases where O_DIRECT fails because of the file
system type. Josh Berkus wanted the first case kept in case we decide
to offer non-direct-io options on machines that support direct i/o.

The new messages are:

* This non-direct I/O option is not used by Postgres.

** This file system and its mount options do not support direct
I/O, e.g. ext4 in journaled mode.

You can see the first one below in my output from Ubuntu:

$ ./test_fsync
Ops-per-test = 2000

Simple non-sync'ed write:
8k write 58.175 ops/sec

Compare file sync methods using one write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
open_datasync n/a
8k write, fdatasync 68.425 ops/sec
8k write, fsync 63.932 ops/sec
fsync_writethrough n/a
open_sync 8k write* 73.785 ops/sec
open_sync 8k direct I/O write 82.929 ops/sec
* This non-direct I/O option is not used by Postgres.

Compare file sync methods using two writes:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
open_datasync n/a
8k write, 8k write, fdatasync 42.728 ops/sec
8k write, 8k write, fsync 43.625 ops/sec
fsync_writethrough n/a
2 open_sync 8k writes* 37.150 ops/sec
2 open_sync 8k direct I/O writes 43.722 ops/sec
* This non-direct I/O option is not used by Postgres.

Compare open_sync with different sizes:
(This is designed to compare the cost of one large
sync'ed write and two smaller sync'ed writes.)
open_sync 16k write 46.428 ops/sec
2 open_sync 8k writes 38.703 ops/sec

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
8k write, fsync, close 65.744 ops/sec
8k write, close, fsync 63.077 ops/sec

I believe test_fsync now matches the backend code. If we decide to
change things, it can be adjusted.

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

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

Attachment Content-Type Size
/rtmp/stars text/x-diff 3.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-01-16 00:30:20 Re: What happened to open_sync_without_odirect?
Previous Message Magnus Hagander 2011-01-15 23:54:10 Re: Include WAL in base backup