Re: RAID 10 Benchmark with different I/O schedulers - Mailing list pgsql-performance

From Craig James
Subject Re: RAID 10 Benchmark with different I/O schedulers
Date
Msg-id 4820A3C2.4000307@emolecules.com
Whole thread Raw
In response to Re: RAID 10 Benchmark with different I/O schedulers (was: Performance increase with elevator=deadline)  (Greg Smith <gsmith@gregsmith.com>)
Responses Re: RAID 10 Benchmark with different I/O schedulers  (Greg Smith <gsmith@gregsmith.com>)
Re: RAID 10 Benchmark with different I/O schedulers  (Matthew Wakeling <matthew@flymine.org>)
List pgsql-performance
Greg Smith wrote:
> On Mon, 5 May 2008, Craig James wrote:
>
>> pgbench -i -s 20 -U test
>
> That's way too low to expect you'll see a difference in I/O schedulers.
> A scale of 20 is giving you a 320MB database, you can fit the whole
> thing in RAM and almost all of it on your controller cache.  What's
> there to schedule?  You're just moving between buffers that are
> generally large enough to hold most of what they need.

Test repeated with:
autovacuum enabled
database destroyed and recreated between runs
pgbench -i -s 600 ...
pgbench -c 10 -t 50000 -n ...

I/O Sched     AVG     Test1  Test2
---------    -----    -----  -----
cfq            705      695    715
noop           758      769    747
deadline       741      705    775
anticipatory   494      477    511

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"
seemsto be measurably slower. 

So it still looks like cfq, noop and deadline are more or less equivalent when used with a battery-backed RAID.

Craig

pgsql-performance by date:

Previous
From: Shaun Thomas
Date:
Subject: Re: multiple joins + Order by + LIMIT query performance issue
Next
From: Dennis Muhlestein
Date:
Subject: Re: Possible Redundancy/Performance Solution