Message-ID: <4B70E117.6070708@2ndquadrant.com>
Date: Mon, 08 Feb 2010 23:14:15 -0500
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Josh Berkus <josh@agliodbs.com>
CC: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-performance@postgresql.org, Albe Laurenz <laurenz.albe@wien.gv.at>
Subject: Re: Linux I/O tuning:  CFQ vs. deadline
References: <4B6FDD26.9010106@2ndquadrant.com>
	<D960CB61B694CF459DCFB4B0128514C203938157@exadv11.host.magwien.gv.at>
	<4B6FD868020000250002F084@gw.wicourts.gov>
	<4B702E05.1000708@2ndquadrant.com> <4B704EA0.3050906@agliodbs.com>
In-Reply-To: <4B704EA0.3050906@agliodbs.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Josh Berkus wrote:
> FWIW, back when deadline was first introduced Mark Wong did some tests
> and found Deadline to be the fastest of 4 on DBT2 ... but only by about
> 5%.  If the read vs. checkpoint analysis is correct, what was happening
> is the penalty for checkpoints on deadline was almost wiping out the
> advantage for reads, but not quite.
>   

Wasn't that before 8.3, where the whole checkpoint spreading logic 
showed up?  That's really a whole different write pattern now than it 
was then.  8.2 checkpoint writes were one big batch write amenable to 
optimizing for throughput.  The new ones are not; the I/O is intermixed 
with reads most of the time.

> Man, we'd need a lot of testing to settle this.  I guess that's why
> Linux gives us the choice of 4 ...
>   

A recent on of these I worked on started with 4096 possible I/O 
configurations we pruned down the most likely good candidates from.  I'm 
almost ready to schedule a week on Mark's HP performance test system in 
the lab now, to try and nail this down in a fully public environment for 
once.

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