From: | Havasvölgyi Ottó <havasvolgyi(dot)otto(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: fsync on ext4 does not work |
Date: | 2011-12-22 10:32:28 |
Message-ID: | CAOryeA3G4+ox3CDQ=xAJFYn50TZmPjOrax-VSk2wqfkvRXZ=2A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I have run fsync_test on this partition, and I got 2500+ for all kind of
sync method.
dmesg says:
blkfront: xvde: barriers enabled
blkfront: xvda: barriers enabled
One thing I haven't mentioned yet, that this a VM virtualized with Xen.
Perhaps this has some effect.
Thanks,
Otto
2011/12/20 Greg Smith <greg(at)2ndquadrant(dot)com>
> On 12/19/2011 10:52 AM, Havasvölgyi Ottó wrote:
>
>> PgSql 9.1.2
>> Debian, 2.6.32 kernel
>> WAL filesystem: ext4 with defaults
>>
>
> There's a pg_test_fsync program included with the postgresql-contrib
> package that might help you sort out what's going on here. This will
> eliminate the possibility that you're doing something wrong with pgbench,
> and give an easy to interpret number relative to the drive RPM rate.
>
> You said default settings, which eliminated "nobarrier" as a cause here.
> The only other thing I know of that can screw up fsync here is using one
> of the incompatible LVM features to build your filesystem. I don't know
> which currently work and don't work, but last I checked there were a few
> ways you could set LVM up that would eliminate filesystem barriers from
> working properly. You might check:
>
> dmesg | grep barrier
>
> To see if you have any kernel messages related to this.
>
> Here's a pg_test_fsync example from a Debian system on 2.6.32 with ext4
> filesystem and 7200 RPM drive, default mount parameters and no LVM:
>
> $ ./pg_test_fsync
> 2000 operations per test
> O_DIRECT supported on this platform for open_datasync and open_sync.
>
> Compare file sync methods using one 8kB write:
> (in wal_sync_method preference order, except fdatasync
> is Linux's default)
> open_datasync n/a
> fdatasync 113.901 ops/sec
> fsync 28.794 ops/sec
> fsync_writethrough n/a
> open_sync 111.726 ops/sec
>
> Compare file sync methods using two 8kB writes:
> (in wal_sync_method preference order, except fdatasync
> is Linux's default)
> open_datasync n/a
> fdatasync 112.637 ops/sec
> fsync 28.641 ops/sec
> fsync_writethrough n/a
> open_sync 55.546 ops/sec
>
> Compare open_sync with different write sizes:
> (This is designed to compare the cost of writing 16kB
> in different write open_sync sizes.)
> 16kB open_sync write 111.909 ops/sec
> 8kB open_sync writes 55.278 ops/sec
> 4kB open_sync writes 28.026 ops/sec
> 2kB open_sync writes 14.002 ops/sec
> 1kB open_sync writes 7.011 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.)
> write, fsync, close 28.836 ops/sec
> write, close, fsync 28.890 ops/sec
>
> Non-Sync'ed 8kB writes:
> write 112113.908 ops/sec
>
> --
> Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
> PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-general<http://www.postgresql.org/mailpref/pgsql-general>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-12-22 15:29:16 | Re: Trying to understand postgres crash |
Previous Message | Shankar Palaniappan | 2011-12-22 09:31:00 | Unable to connect to PostgreSQL server : Could not get socket error status |