Re: Best setting for wal_sync_method

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "'Ravi Krishna *EXTERN*'" <srkrishna(at)outlook(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Best setting for wal_sync_method
Date: 2015-05-08 08:08:53
Message-ID: A737B7A37273E048B164557ADEF4A58B3660D123@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Ravi Krishna wrote:
> On RHEL 6.4 which is the best setting for wal_sync_method for write intensive operations. Is the
> default fdatasync good for all conditions, including reliability.

Yes; you should not change that.
At least not without running performance tests.
There is the pg_test_fsync contrib that can help you test the different methods.
http://www.postgresql.org/docs/current/static/pgtestfsync.html

> Speaking to the sys admins we found that the file system where the WAL was written to did not have
> direct_io and hence all writes were getting buffered. So we enabled direct_io on that FS and now
> writes are order of magnitude slower (5x times).
>
> It seems PG already uses O_DIRECT for WAL. So is the enabling of direct_io in the mount options of the
> FS totally redundant. It definitely has a serious performance impact.

You should not use direct I/O with PostgreSQL.

All that is required is that the file system and the underlying hardware honors
the fsync() (or fdatasync()) system calls, i.e. it is guaranteed that when these
functions return, the written data cannot get lost by a subsequent crash.
You want to make very sure that that is the case, otherwise your database
*will* be corrupted after a crash some day.

Yours,
Laurenz Albe

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Andres Freund 2015-05-08 15:03:40 Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Previous Message Albe Laurenz 2015-05-08 07:50:41 Re: Schema Consolidation in PostgreSQL