Message-ID: <4C699BE2.50606@2ndquadrant.com>
Date: Mon, 16 Aug 2010 16:13:22 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Andres Freund <andres@anarazel.de>
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
References: <201008131817.o7DIH1b03550@momjian.us>
	<4C6591D9.1080206@2ndquadrant.com>
	<5687A8AD-CA70-4272-A32C-6AE5F491CEA4@richrelevance.com>
	<4C69796D.9000408@2ndquadrant.com>
	<20100816200227.GA3911@anarazel.de>
In-Reply-To: <20100816200227.GA3911@anarazel.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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)

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