From: Andres Freund <andres@anarazel.de>
To: pgsql-performance@postgresql.org
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: Scott Carey <scott@richrelevance.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Kenneth Cox <kenstir@gmail.com>
Subject: Re: Advice configuring ServeRAID 8k for performance
Date: Tue, 17 Aug 2010 11:37:38 +0200
Message-ID: <201008171137.39078.andres@anarazel.de> (raw)
In-Reply-To: <4C6A4856.2050103@2ndquadrant.com>
References: <201008131817.o7DIH1b03550@momjian.us>
<20100816210552.GC3911@anarazel.de>
<4C6A4856.2050103@2ndquadrant.com>
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
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: andres@anarazel.de, greg@2ndquadrant.com, scott@richrelevance.com, bruce@momjian.us, kenstir@gmail.com
Subject: Re: Advice configuring ServeRAID 8k for performance
In-Reply-To: <201008171137.39078.andres@anarazel.de>
* 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