From: Andres Freund <andres@anarazel.de>
To: pgsql-performance@postgresql.org
Subject: Re: Advice configuring ServeRAID 8k for performance
Date: Tue, 17 Aug 2010 11:37:38 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.35-rc4-andres; KDE/4.5.0; x86_64; ; )
Cc: Greg Smith <greg@2ndquadrant.com>, Scott Carey <scott@richrelevance.com>,
	Bruce Momjian <bruce@momjian.us>, Kenneth Cox <kenstir@gmail.com>
References: <201008131817.o7DIH1b03550@momjian.us>
	<20100816210552.GC3911@anarazel.de>
	<4C6A4856.2050103@2ndquadrant.com>
In-Reply-To: <4C6A4856.2050103@2ndquadrant.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201008171137.39078.andres@anarazel.de>

On Tuesday 17 August 2010 10:29:10 Greg Smith wrote:
> Andres Freund wrote:
> > An fsync() equals a barrier so it has the effect of stopping
> > reordering around it - especially on systems with larger multi-disk
> > arrays thats pretty expensive.
> > You can achieve surprising speedups, at least in my experience, by
> > forcing the kernel to start writing out pages *without enforcing
> > barriers* first and then later enforce a barrier to be sure its
> > actually written out.
> 
> Standard practice on high performance systems with good filesystems and
> a battery-backed controller is to turn off barriers anyway.  That's one
> of the first things to tune on XFS for example, when you have a reliable
> controller.  I don't have enough data on ext4 to comment on tuning for
> it yet.
> 
> The sole purpose for the whole Linux write barrier implementation in my
> world is to flush the drive's cache, when the database does writes onto
> cheap SATA drives that will otherwise cache dangerously.  Barriers don't
> have any place on a serious system that I can see.  The battery-backed
> RAID controller you have to use to make fsync calls fast anyway can do
> some simple write reordering, but the operating system doesn't ever have
> enough visibility into what it's doing to make intelligent decisions
> about that anyway.
Even if were not talking about a write barrier in an "ensure its written out 
of the cache" way it still stops the io-scheduler from reordering. I 
benchmarked it (custom app) and it was very noticeable on a bunch of different 
systems (with a good BBUed RAID).

Andres