Re: fsync on ext4 does not work

Поиск
Список
Период
Сортировка
От Havasvölgyi Ottó
Тема Re: fsync on ext4 does not work
Дата
Msg-id CAOryeA3G4+ox3CDQ=xAJFYn50TZmPjOrax-VSk2wqfkvRXZ=2A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: fsync on ext4 does not work  (Greg Smith <greg@2ndQuadrant.com>)
Список 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@2ndquadrant.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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

В списке pgsql-general по дате отправления:

Предыдущее
От: Raghavendra
Дата:
Сообщение: Re: Why vacumming performed on template1 with initdb command ?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Trying to understand postgres crash