Date: Mon, 16 Aug 2010 22:18:38 +0200
From: Andres Freund <andres@anarazel.de>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Scott Carey <scott@richrelevance.com>, Bruce Momjian <bruce@momjian.us>,
	Kenneth Cox <kenstir@gmail.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Advice configuring ServeRAID 8k for performance
Message-ID: <20100816201838.GB3911@anarazel.de>
References: <201008131817.o7DIH1b03550@momjian.us>
	<4C6591D9.1080206@2ndquadrant.com>
	<5687A8AD-CA70-4272-A32C-6AE5F491CEA4@richrelevance.com>
	<4C69796D.9000408@2ndquadrant.com>
	<20100816200227.GA3911@anarazel.de>
	<4C699BE2.50606@2ndquadrant.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4C699BE2.50606@2ndquadrant.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

On Mon, Aug 16, 2010 at 04:13:22PM -0400, Greg Smith wrote:
> Andres Freund wrote:
> >Or use -o sync. Or configure a ridiciuosly low dirty_memory amount
> >(which has a problem on large systems because 1% can still be too
> >much. Argh.)...
>
> -o sync completely trashes performance, and trying to set the
> dirty_ratio values to even 1% doesn't really work due to things like
> the "congestion avoidance" code in the kernel.  If you sync a lot
> more often, which putting the WAL on the same disk as the database
> accidentally does for you, that works surprisingly well at avoiding
> this whole class of problem on ext3.  A really good solution is
> going to take a full rewrite of the PostgreSQL checkpoint logic
> though, which will get sorted out during 9.1 development.  (cue
> dramatic foreshadowing music here)
-o sync works ok enough for the data partition (surely not the wal) if you make the
background writer less aggressive.

But yes. A new checkpointing logic + a new syncing logic
(prepare_fsync() earlier and then fsync() later) would be a nice
thing. Do you plan to work on that?

Andres