Re: RAID 10 Benchmark with different I/O schedulers

From: Craig James <craig_james(at)emolecules(dot)com>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: RAID 10 Benchmark with different I/O schedulers
Date: 2008-05-06 18:30:26
Message-ID: 4820A3C2.4000307@emolecules.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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" seems to 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Dennis Muhlestein 2008-05-06 18:31:01 Re: Possible Redundancy/Performance Solution
Previous Message Shaun Thomas 2008-05-06 18:24:33 Re: multiple joins + Order by + LIMIT query performance issue