From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Миша Тюрин <tmihail(at)bk(dot)ru> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Wal sync odirect |
Date: | 2013-07-22 07:01:53 |
Message-ID: | 51ECD8E1.1010000@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/21/2013 10:01 PM, Миша Тюрин wrote:
> hi, list. there are my proposal. i would like to tell about odirect in wal sync in wal_level is higher than minimal. i think in my case when wal traffic is up to 1gb per 2-3 minutes but discs hardware with 2gb bbu cache (or maybe ssd under wal) - there would be better if wall traffic could not harm os memory eviction. and i do not use streaming. my archive command may read wal directly without os cache. just opinion, i have not done any tests yet. but i am still under the some memory eviction anomaly.
PostgreSQL already uses O_DIRECT for WAL writes if you use O_SYNC mode
for WAL writes. See comments in src/include/access/xlogdefs.h (search
for O_DIRECT). You should also examine
src/backend/access/transam/xlog.c, particularly the function
get_sync_bit(...)
Try doing some tests with pg_test_fsync, see how performance looks. If
your theory is right and WAL traffic is putting pressure on kernel write
buffers, using fsync=open_datasync - which should be the default on
Linux - may help.
I'd recommend doing some detailed tracing and performance measurements
before trying to proceed further.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wanner | 2013-07-22 07:13:37 | Re: Proposal: template-ify (binary) extensions |
Previous Message | didier | 2013-07-22 04:21:33 | Re: Improvement of checkpoint IO scheduler for stable transaction responses |