From mark.kirkwood@catalyst.net.nz Fri Jun  18 01:39:57 2010
Received: from maia.hub.org (maia-2.hub.org [200.46.204.251])
	by mail.postgresql.org (Postfix) with ESMTP id D2997632DBD
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu, 17 Jun 2010 22:39:57 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia,
	port 10024) with ESMTP id 30454-03
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 18 Jun 2010 01:39:49 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.catalyst.net.nz (bertrand.catalyst.net.nz [202.78.240.40])
	by mail.postgresql.org (Postfix) with ESMTP id C712E632CEC
	for <pgsql-performance@postgresql.org>;
	Thu, 17 Jun 2010 22:39:50 -0300 (ADT)
Received: from localhost (localhost [127.0.0.1])
	by mail.catalyst.net.nz (Postfix) with ESMTP id A425968429
	for <pgsql-performance@postgresql.org>;
	Fri, 18 Jun 2010 13:39:46 +1200 (NZST)
X-Virus-Scanned: Debian amavisd-new at catalyst.net.nz
Received: from mail.catalyst.net.nz ([127.0.0.1])
	by localhost (bertrand.catalyst.net.nz [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 6GhsQcGz6fh9 for <pgsql-performance@postgresql.org>;
	Fri, 18 Jun 2010 13:39:45 +1200 (NZST)
Received: from [192.168.1.11] (122-58-208-29.jetstream.xtra.co.nz
	[122.58.208.29]) (Authenticated sender: mark.kirkwood)
	by mail.catalyst.net.nz (Postfix) with ESMTPSA id 13BF76842C
	for <pgsql-performance@postgresql.org>;
	Fri, 18 Jun 2010 13:39:44 +1200 (NZST)
Message-ID: <4C1ACE5F.1080802@catalyst.net.nz>
Date: Fri, 18 Jun 2010 13:39:43 +1200
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: wal_synch_method = open_sync safe on RHEL 5.5?
Content-Type: multipart/alternative;
	boundary="------------030400080305000705090308"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.791 tagged_above=-10 required=5 tests=BAYES_50=0.8,
	HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201006/324
X-Sequence-Number: 39180

This is a multi-part message in MIME format.
--------------030400080305000705090308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Some more on the RHEL 5.5 system I'm helping to setup. Some benchmarking 
using pgbench appeared to suggest that wal_sync_method=open_sync was a 
little faster than fdatasync [1]. Now I recall some discussion about 
this enabling direct io and the general flakiness of this on Linux, so 
is the option regarded as safe?

[1] The workout:

$ pgbench -i -s 1000 bench
$ pgbench -c [1,2,4,8,32,64,128] -t 10000

Performance peaked around 2500 tps @32 clients using open_sync and 2200 
with fdatasync. However the disk arrays are on a SAN and I suspect that 
when testing with fdatasync later in the day there may have been 
workload 'leakage' from other hosts hitting the SAN.

--------------030400080305000705090308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<font size="-1"><font face="Helvetica">Some more on the RHEL 5.5 system
I'm helping to setup. Some benchmarking using pgbench appeared to
suggest that wal_sync_method=open_sync was a little faster than
fdatasync [1]. Now I recall some discussion about this enabling direct
io and the general flakiness of this on Linux, so is the option
regarded as safe?<br>
<br>
[1] The workout: <br>
<br>
$ pgbench -i -s 1000 bench<br>
$ pgbench -c [1,2,4,8,32,64,128] -t 10000<br>
<br>
Performance peaked around 2500 tps @32 clients using open_sync and 2200
with fdatasync. However the disk arrays are on a SAN and I suspect that
when testing with fdatasync later in the day there may have been
workload 'leakage' from other hosts hitting the SAN.<br>
</font></font>
</body>
</html>

--------------030400080305000705090308--



From greg@2ndquadrant.com Fri Jun  18 03:29:48 2010
Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id 1032963232D
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 18 Jun 2010 00:29:48 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 38878-03
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 18 Jun 2010 03:29:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10])
	by mail.postgresql.org (Postfix) with ESMTP id 7C4866322F9
	for <pgsql-performance@postgresql.org>;
	Fri, 18 Jun 2010 00:29:40 -0300 (ADT)
Received: from [192.168.1.6] (pool-96-244-14-10.bltmmd.fios.verizon.net
	[96.244.14.10])
	by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis)
	id 0MIPfz-1OO4xp0Cel-0045gi; Fri, 18 Jun 2010 05:29:38 +0200
Message-ID: <4C1AE820.6020506@2ndquadrant.com>
Date: Thu, 17 Jun 2010 23:29:36 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
CC: pgsql-performance@postgresql.org
Subject: Re: wal_synch_method = open_sync safe on RHEL 5.5?
References: <4C1ACE5F.1080802@catalyst.net.nz>
In-Reply-To: <4C1ACE5F.1080802@catalyst.net.nz>
Content-Type: multipart/alternative;
	boundary="------------080106020707040303080104"
X-Provags-ID: V01U2FsdGVkX1+PlF92MHhnuJY1MPsfMpjIWE2UFSCjjJKwvlI
	IoI5riOUPknoJAGL7NDcqsTxfBbHPmocnhnlfez3WzqOwFtT97
	AuR7aA+8GxscKOWYJ7svkiKDwRc7Fw7
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=-10 required=5 tests=BAYES_20=-0.001,
	HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001
X-Spam-Level: 
X-Archive-Number: 201006/325
X-Sequence-Number: 39181

This is a multi-part message in MIME format.
--------------080106020707040303080104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mark Kirkwood wrote:
> Now I recall some discussion about this enabling direct io and the 
> general flakiness of this on Linux, so is the option regarded as safe?

No one has ever refuted the claims in 
http://archives.postgresql.org/pgsql-hackers/2007-10/msg01310.php that 
it can be unsafe under a heavy enough level of mixed load on RHEL5.  
Given the performance benefits are marginal on ext3, I haven't ever 
considered it worth the risk.  (I've seen much larger gains on 
Linux+Veritas VxFS).  From what I've seen, recent Linux kernel work has 
reinforced that the old O_SYNC implementation was full of bugs now that 
more work is being done to improve that area.  My suspicion (based on no 
particular data, just what I've seen it tested with) is that it only 
really worked before in the very specific way that Oracle does O_SYNC 
writes, which is different from what PostgreSQL does.

P.S. Be wary of expecting pgbench to give you useful numbers on a single 
run.  For the default write-heavy test, I recommend three runs of 10 
minutes each (-T 600 on recent PostgreSQL versions) before I trust any 
results it gives.  You can get useful data from the select-only test in 
only a few seconds, but not the one that writes a bunch.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us


--------------080106020707040303080104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mark Kirkwood wrote:
<blockquote cite="mid:4C1ACE5F.1080802@catalyst.net.nz" type="cite">
  <meta http-equiv="content-type" content="text/html; ">
  <font size="-1"><font face="Helvetica">Now I recall some discussion
about this enabling direct
io and the general flakiness of this on Linux, so is the option
regarded as safe?<br>
  </font></font></blockquote>
<br>
No one has ever refuted the claims in
<a class="moz-txt-link-freetext" href="http://archives.postgresql.org/pgsql-hackers/2007-10/msg01310.php">http://archives.postgresql.org/pgsql-hackers/2007-10/msg01310.php</a> that
it can be unsafe under a heavy enough level of mixed load on RHEL5.&nbsp;
Given the performance benefits are marginal on ext3, I haven't ever
considered it worth the risk.&nbsp; (I've seen much larger gains on
Linux+Veritas VxFS).&nbsp; From what I've seen, recent Linux kernel work has
reinforced that the old O_SYNC implementation was full of bugs now that
more work is being done to improve that area.&nbsp; My suspicion (based on
no particular data, just what I've seen it tested with) is that it only
really worked before in the very specific way that Oracle does O_SYNC
writes, which is different from what PostgreSQL does.<br>
<br>
P.S. Be wary of expecting pgbench to give you useful numbers on a
single run.&nbsp; For the default write-heavy test, I recommend three runs
of 10 minutes each (-T 600 on recent PostgreSQL versions) before I
trust any results it gives.&nbsp; You can get useful data from the
select-only test in only a few seconds, but not the one that writes a
bunch.<br>
<br>
<pre class="moz-signature" cols="72">-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
<a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a>   <a class="moz-txt-link-abbreviated" href="http://www.2ndQuadrant.us">www.2ndQuadrant.us</a>
</pre>
</body>
</html>

--------------080106020707040303080104--



From mark@mark.mielke.cc Fri Jun  18 03:57:54 2010
Received: from maia.hub.org (maia-2.hub.org [200.46.204.251])
	by mail.postgresql.org (Postfix) with ESMTP id AD875632747
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 18 Jun 2010 00:57:54 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia,
	port 10024) with ESMTP id 69339-08
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 18 Jun 2010 03:57:46 +0000 (UTC)
X-Greylist: delayed 00:21:30.065531 by SQLgrey-1.7.6
Received: from mail-01.primus.ca (smtp-noauth7.primus.ca [216.254.180.38])
	by mail.postgresql.org (Postfix) with ESMTP id 11EEF632712
	for <pgsql-performance@postgresql.org>;
	Fri, 18 Jun 2010 00:57:46 -0300 (ADT)
Received: from [206.191.44.11] (helo=bambi.pccyber.com)
	by mail-01.primus.ca with esmtp (Exim 4.69)
	(envelope-from <mark@mark.mielke.cc>)
	id 1OPSNG-0003Yq-0i; Thu, 17 Jun 2010 23:36:10 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by bambi.pccyber.com (Postfix) with ESMTP id 4E5271B49BC;
	Thu, 17 Jun 2010 23:36:08 -0400 (EDT)
X-Virus-Scanned: amavisd-new at pccyber.com
Received: from bambi.pccyber.com ([127.0.0.1])
	by localhost (bambi.pccyber.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 3HY1vQjMJ-29; Thu, 17 Jun 2010 23:36:04 -0400 (EDT)
Received: from [173.35.103.0]
	(CPE0050fca9b0e1-CM0018c0d3a5ba.cpe.net.cable.rogers.com
	[173.35.103.0]) (Authenticated sender: mark@pccyber.com)
	by bambi.pccyber.com (Postfix) with ESMTPA id 17BFB1B49AC;
	Thu, 17 Jun 2010 23:36:04 -0400 (EDT)
Message-ID: <4C1AE9A3.4080307@mark.mielke.cc>
Date: Thu, 17 Jun 2010 23:36:03 -0400
From: Mark Mielke <mark@mark.mielke.cc>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4
MIME-Version: 1.0
To: Greg Smith <greg@2ndquadrant.com>
CC: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>,
	pgsql-performance@postgresql.org
Subject: Re: wal_synch_method = open_sync safe on RHEL 5.5?
References: <4C1ACE5F.1080802@catalyst.net.nz>
	<4C1AE820.6020506@2ndquadrant.com>
In-Reply-To: <4C1AE820.6020506@2ndquadrant.com>
Content-Type: multipart/alternative;
	boundary="------------020705000605070702090703"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=-10 required=5 tests=BAYES_20=-0.001,
	HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001
X-Spam-Level: 
X-Archive-Number: 201006/326
X-Sequence-Number: 39182

This is a multi-part message in MIME format.
--------------020705000605070702090703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The conclusion I read was that Linux O_SYNC behaves like O_DSYNC on 
other systems. For WAL, this seems satisfactory?

Personally, I use fdatasync(). I wasn't able to measure a reliable 
difference for my far more smaller databases, and fdatasync() seems 
reliable and fast enough, that fighting with O_SYNC doesn't seem to be 
worth it. Also, technically speaking, fdatasync() appeals more to me, as 
it allows the system to buffer while it can, and the application to 
instruct it across what boundaries it should not buffer. O_SYNC / 
O_DSYNC seem to imply a requirement that it does a synch on every block. 
My gut tells me that fdatasync() gives the operating system more 
opportunities to optimize (whether it does or not is a different issue 
:-) ).

Cheers,
mark


On 06/17/2010 11:29 PM, Greg Smith wrote:
> Mark Kirkwood wrote:
>> Now I recall some discussion about this enabling direct io and the 
>> general flakiness of this on Linux, so is the option regarded as safe?
>
> No one has ever refuted the claims in 
> http://archives.postgresql.org/pgsql-hackers/2007-10/msg01310.php that 
> it can be unsafe under a heavy enough level of mixed load on RHEL5.  
> Given the performance benefits are marginal on ext3, I haven't ever 
> considered it worth the risk.  (I've seen much larger gains on 
> Linux+Veritas VxFS).  From what I've seen, recent Linux kernel work 
> has reinforced that the old O_SYNC implementation was full of bugs now 
> that more work is being done to improve that area.  My suspicion 
> (based on no particular data, just what I've seen it tested with) is 
> that it only really worked before in the very specific way that Oracle 
> does O_SYNC writes, which is different from what PostgreSQL does.
>
> P.S. Be wary of expecting pgbench to give you useful numbers on a 
> single run.  For the default write-heavy test, I recommend three runs 
> of 10 minutes each (-T 600 on recent PostgreSQL versions) before I 
> trust any results it gives.  You can get useful data from the 
> select-only test in only a few seconds, but not the one that writes a 
> bunch.
>
> -- 
> Greg Smith  2ndQuadrant US  Baltimore, MD
> PostgreSQL Training, Services and Support
> greg@2ndQuadrant.com    www.2ndQuadrant.us
>    


-- 
Mark Mielke<mark@mielke.cc>


--------------020705000605070702090703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
The conclusion I read was that Linux O_SYNC behaves like O_DSYNC on
other systems. For WAL, this seems satisfactory?<br>
<br>
Personally, I use fdatasync(). I wasn't able to measure a reliable
difference for my far more smaller databases, and fdatasync() seems
reliable and fast enough, that fighting with O_SYNC doesn't seem to be
worth it. Also, technically speaking, fdatasync() appeals more to me,
as it allows the system to buffer while it can, and the application to
instruct it across what boundaries it should not buffer. O_SYNC /
O_DSYNC seem to imply a requirement that it does a synch on every
block. My gut tells me that fdatasync() gives the operating system more
opportunities to optimize (whether it does or not is a different issue
:-) ).<br>
<br>
Cheers,<br>
mark<br>
<br>
<br>
On 06/17/2010 11:29 PM, Greg Smith wrote:
<blockquote cite="mid:4C1AE820.6020506@2ndquadrant.com" type="cite">
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
Mark Kirkwood wrote:
  <blockquote cite="mid:4C1ACE5F.1080802@catalyst.net.nz" type="cite">
    <meta http-equiv="content-type"
 content="text/html; charset=ISO-8859-1">
    <font size="-1"><font face="Helvetica">Now I recall some discussion
about this enabling direct
io and the general flakiness of this on Linux, so is the option
regarded as safe?<br>
    </font></font></blockquote>
  <br>
No one has ever refuted the claims in
  <a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://archives.postgresql.org/pgsql-hackers/2007-10/msg01310.php">http://archives.postgresql.org/pgsql-hackers/2007-10/msg01310.php</a>
that
it can be unsafe under a heavy enough level of mixed load on RHEL5.&nbsp;
Given the performance benefits are marginal on ext3, I haven't ever
considered it worth the risk.&nbsp; (I've seen much larger gains on
Linux+Veritas VxFS).&nbsp; From what I've seen, recent Linux kernel work has
reinforced that the old O_SYNC implementation was full of bugs now that
more work is being done to improve that area.&nbsp; My suspicion (based on
no particular data, just what I've seen it tested with) is that it only
really worked before in the very specific way that Oracle does O_SYNC
writes, which is different from what PostgreSQL does.<br>
  <br>
P.S. Be wary of expecting pgbench to give you useful numbers on a
single run.&nbsp; For the default write-heavy test, I recommend three runs
of 10 minutes each (-T 600 on recent PostgreSQL versions) before I
trust any results it gives.&nbsp; You can get useful data from the
select-only test in only a few seconds, but not the one that writes a
bunch.<br>
  <br>
  <pre class="moz-signature" cols="72">-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a>   <a
 moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="http://www.2ndQuadrant.us">www.2ndQuadrant.us</a>
  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc">&lt;mark@mielke.cc&gt;</a>
</pre>
</body>
</html>

--------------020705000605070702090703--



From mark.kirkwood@catalyst.net.nz Fri Jun  18 04:20:03 2010
Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 901566326E4
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 18 Jun 2010 01:20:03 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 22885-10
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 18 Jun 2010 04:19:56 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.catalyst.net.nz (bertrand.catalyst.net.nz [202.78.240.40])
	by mail.postgresql.org (Postfix) with ESMTP id A14A0632239
	for <pgsql-performance@postgresql.org>;
	Fri, 18 Jun 2010 01:19:56 -0300 (ADT)
Received: from localhost (localhost [127.0.0.1])
	by mail.catalyst.net.nz (Postfix) with ESMTP id 67F4268498
	for <pgsql-performance@postgresql.org>;
	Fri, 18 Jun 2010 16:19:54 +1200 (NZST)
X-Virus-Scanned: Debian amavisd-new at catalyst.net.nz
Received: from mail.catalyst.net.nz ([127.0.0.1])
	by localhost (bertrand.catalyst.net.nz [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 3p4K-qO2YIIa for <pgsql-performance@postgresql.org>;
	Fri, 18 Jun 2010 16:19:53 +1200 (NZST)
Received: from [192.168.1.11] (122-58-208-29.jetstream.xtra.co.nz
	[122.58.208.29]) (Authenticated sender: mark.kirkwood)
	by mail.catalyst.net.nz (Postfix) with ESMTPSA id A42CF339C5
	for <pgsql-performance@postgresql.org>;
	Fri, 18 Jun 2010 16:19:53 +1200 (NZST)
Message-ID: <4C1AF3E8.4030608@catalyst.net.nz>
Date: Fri, 18 Jun 2010 16:19:52 +1200
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: wal_synch_method = open_sync safe on RHEL 5.5?
References: <4C1ACE5F.1080802@catalyst.net.nz>
	<4C1AE820.6020506@2ndquadrant.com>
In-Reply-To: <4C1AE820.6020506@2ndquadrant.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.79 tagged_above=-10 required=5 tests=BAYES_50=0.8,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201006/328
X-Sequence-Number: 39184

On 18/06/10 15:29, Greg Smith wrote:
>
> P.S. Be wary of expecting pgbench to give you useful numbers on a 
> single run.  For the default write-heavy test, I recommend three runs 
> of 10 minutes each (-T 600 on recent PostgreSQL versions) before I 
> trust any results it gives.  You can get useful data from the 
> select-only test in only a few seconds, but not the one that writes a 
> bunch.
>

Yeah, I did several runs of each, and a couple with -c 128 and -t 100000 
to give the setup a good workout (also 2000-2400 tps, nice to see a well 
behaved SAN).


Cheers

Mark



From greg@2ndquadrant.com Fri Jun  18 06:03:12 2010
Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id A1C54632208
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 18 Jun 2010 03:03:12 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 55806-06
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 18 Jun 2010 06:03:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10])
	by mail.postgresql.org (Postfix) with ESMTP id 5BA1C6302CB
	for <pgsql-performance@postgresql.org>;
	Fri, 18 Jun 2010 03:03:05 -0300 (ADT)
Received: from [192.168.0.105] (pool-96-244-14-10.bltmmd.fios.verizon.net
	[96.244.14.10])
	by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis)
	id 0Mdo4b-1ObONa2GD7-00Pfeq; Fri, 18 Jun 2010 08:03:00 +0200
Message-ID: <4C1B0C11.1010204@2ndquadrant.com>
Date: Fri, 18 Jun 2010 02:02:57 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Mark Mielke <mark@mark.mielke.cc>
CC: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>,
	pgsql-performance@postgresql.org
Subject: Re: wal_synch_method = open_sync safe on RHEL 5.5?
References: <4C1ACE5F.1080802@catalyst.net.nz>
	<4C1AE820.6020506@2ndquadrant.com>
	<4C1AE9A3.4080307@mark.mielke.cc>
In-Reply-To: <4C1AE9A3.4080307@mark.mielke.cc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V01U2FsdGVkX19s5O3Z8kdrRV7xjmVAcR/y63EndLxGtc/X7J1
	Wa6MehjsQdlRS98D5TBCiOe4w1q4s1MFxFKkHYxy4gQ+4lBCji
	897DXc9ohODG0txwRA2hiqNJmXsw9bh
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.8 tagged_above=-10 required=5 tests=BAYES_50=0.8,
	RCVD_IN_DNSWL_NONE=-0.0001
X-Spam-Level: 
X-Archive-Number: 201006/329
X-Sequence-Number: 39185

Mark Mielke wrote:
> The conclusion I read was that Linux O_SYNC behaves like O_DSYNC on 
> other systems. For WAL, this seems satisfactory?

It would be if it didn't have any bugs or limitiations, but it does.  
The one pointed out in the message I linked to suggests that a mix of 
buffered and O_SYNC direct I/O can cause a write error, with the exact 
behavior you get depending on the kernel version.  That's a path better 
not explored as I see it.

The kernels that have made some effort to implement this correctly 
actually expose O_DSYNC, on newer Linux systems.  My current opinion is 
that if you only have Linux O_SYNC, don't use it.  The ones with O_DSYNC 
haven't been around for long enough to be proven or disproven as 
effective yet.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us