pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Greg Smith <gsmith@gregsmith.com>
To: pgsql-performance@postgresql.org
Subject: Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
Date: Thu, 13 Mar 2008 17:27:09 -0400 (EDT)
Message-ID: <Pine.GSO.4.64.0803131710520.5221@westnet.com> (raw)
In-Reply-To: <20080313140618.3449ba58@commandprompt.com>
References: <f966c2ee0803052142l6a105678jfe2da92a0d9371@mail.gmail.com>
	<f966c2ee0803052143k4570d771o6c300647d3b987d@mail.gmail.com>
	<20080306060829.GA21084@a-kretschmer.de>
	<bf54be870803052215y5bb56235k5ea05ada1d701022@mail.gmail.com>
	<47CF8EA6.8070503@mark.mielke.cc>
	<20080306063643.GB21084@a-kretschmer.de>
	<f966c2ee0803052243w723e2866gbfc37128620d1c6d@mail.gmail.com>
	<B94D3180-BB72-43EB-BA1E-90CF53705386@fastcrypt.com>
	<f966c2ee0803060358k14dd7374h8ef3f4ca0818b04@mail.gmail.com>
	<3E9C3A51-C28E-4B75-9739-E344DAC72880@fastcrypt.com>
	<f966c2ee0803060443j3d9c1b66x5f59e00d084e841c@mail.gmail.com>
	<Pine.GSO.4.64.0803060813570.11897@westnet.com>
	<47D00DB2.7040007@emolecules.com>
	<18451.1204824562@sss.pgh.pa.us>
	<47D0AFC1.5070305@emolecules.com>
	<47D8B3B6.3010606@emolecules.com>
	<20080312225554.52f6275b@commandprompt.com>
	<47D9402A.3050903@emolecules.com>
	<Pine.GSO.4.64.0803131151430.24943@westnet.com>
	<20080313140618.3449ba58@commandprompt.com>

On Thu, 13 Mar 2008, Joshua D. Drake wrote:

> Greg Smith <gsmith@gregsmith.com> wrote:
>>>> wal_sync_method = open_sync
>>
>> There was a bug report I haven't had a chance to investigate yet that
>> suggested some recent Linux versions have issues when using
>> open_sync. I'd suggest popping that back to the default for now
>> unless you have time to really do a long certification process that
>> your system runs reliably with it turned on.
>
> Well the default would be ugly, that's fsync, fdatasync is probably a
> better choice in that case.

I haven't found fdatasync to be significantly better in my tests on Linux 
but I never went out of my way to try and quantify it.  My understanding 
is that some of the write barrier implementation details on ext3 
filesystems make any sync call a relatively heavy operation but I haven't 
poked at the code yet to figure out why.

There are really some substantial gains for WAL-heavy loads under Linux 
just waiting for someone to dig into this more.  For example, I have a 
little plan sitting here to allow opening the WAL files with noatime even 
if the rest of the filesystem can't be mounted that way, which would 
collapse one of the big reasons to use a separate WAL disk.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD



view thread (45+ messages)  latest in thread

Message-ID: <Pine.GSO.4.64.0803131710520.5221@westnet.com>
Permalink:  ../Pine.GSO.4.64.0803131710520.5221@westnet.com/
Also on:    postgresql.org/message-id/Pine.GSO.4.64.0803131710520.5221@westnet.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: gsmith@gregsmith.com
  Subject: Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  In-Reply-To: <Pine.GSO.4.64.0803131710520.5221@westnet.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox