Message-ID: <4820C30A.8010709@emolecules.com>
Date: Tue, 06 May 2008 13:43:54 -0700
From: Craig James <craig_james@emolecules.com>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Greg Smith <gsmith@gregsmith.com>
CC: pgsql-performance@postgresql.org
Subject: Re: RAID 10 Benchmark with different I/O schedulers
References: 
 <D960CB61B694CF459DCFB4B0128514C201FA62C8@exadv11.host.magwien.gv.at>
	<C050E63A-2209-4E89-AA99-6A327CCE7380@torgo.978.org>
	<Pine.LNX.4.64.0804111736580.20402@aragorn.flymine.org>
	<47FFA7FF.10801@postnewspapers.com.au>
	<544D07A2-EB3F-4D91-A749-0C4D5D38AB80@gmail.com>
	<481F992D.7070509@emolecules.com>
	<Pine.GSO.4.64.0805052354120.3752@westnet.com>
	<4820A3C2.4000307@emolecules.com>
	<Pine.GSO.4.64.0805061605030.11474@westnet.com>
In-Reply-To: <Pine.GSO.4.64.0805061605030.11474@westnet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Greg Smith wrote:
> On Tue, 6 May 2008, Craig James wrote:
> 
>> I only did two runs of each, which took about 24 minutes.  Like the 
>> first round of tests, the "noise" in the measurements (about 10%) 
>> exceeds the difference between scheduler-algorithm performance, except 
>> that "anticipatory" seems to be measurably slower.
> 
> Those are much better results.  Any test that says anticipatory is 
> anything other than useless for database system use with a good 
> controller I presume is broken, so that's how I know you're in the right 
> ballpark now but weren't before.
> 
> In order to actually get some useful data out of the noise that is 
> pgbench, you need a lot more measurements of longer runs.  As 
> perspective, the last time I did something in this area, in order to get 
> enough data to get a clear picture I ran tests for 12 hours.  I'm hoping 
> to repeat that soon with some more common hardware that gives useful 
> results I can give out.

This data is good enough for what I'm doing.  There were reports from non-RAID users that the I/O scheduling could make as much as a 4x difference in performance (which makes sense for non-RAID), but these tests show me that three of the four I/O schedulers are within 10% of each other.  Since this matches my intuition of how battery-backed RAID will work, I'm satisfied.  If our servers get overloaded to the point where 10% matters, then I need a much more dramatic solution, like faster machines or more machines.

Craig