Message-ID: <481F992D.7070509@emolecules.com>
Date: Mon, 05 May 2008 16:33:01 -0700
From: Craig James <craig_james@emolecules.com>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: RAID 10 Benchmark with different I/O schedulers (was: Performance
	increase with elevator=deadline)
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>
In-Reply-To: <544D07A2-EB3F-4D91-A749-0C4D5D38AB80@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I had the opportunity to do more testing on another new server to see whether the kernel's I/O scheduling makes any difference.  Conclusion: On a battery-backed RAID 10 system, the kernel's I/O scheduling algorithm has no effect.  This makes sense, since a battery-backed cache will supercede any I/O rescheduling that the kernel tries to do.

Hardware:
 Dell 2950
 8 CPU (Intel 2GHz Xeon)
 8 GB memory
 Dell Perc 6i with battery-backed cache
 RAID 10 of 8x 146GB SAS 10K 2.5" disks

Software:
 Linux 2.6.24, 64-bit
    XFS file system
 Postgres 8.3.0
    max_connections = 1000                                                      
    shared_buffers = 2000MB                                                     
    work_mem = 256MB                                                            
    max_fsm_pages = 1000000                                                     
    max_fsm_relations = 5000                                                    
    synchronous_commit = off                                                    
    wal_buffers = 256kB                                                         
    checkpoint_segments = 30                                                    
    effective_cache_size = 4GB                                                  

Each test was run 5 times:
  drop database test
  create database test
  pgbench -i -s 20 -U test
  pgbench -c 10 -t 50000 -v -U test

The I/O scheduler was changed on-the-fly using (for example) "echo cfq >/sys/block/sda/queue/scheduler".

Autovacuum was turned off during the test.

Here are the results.  The numbers are those reported as "tps = xxxx (including connections establishing)" (which were almost identical to the "excluding..." tps number).

I/O Sched     AVG     Test1  Test2  Test3  Test4  Test5
---------    -----    -----  -----  -----  -----  -----
cfq           3355     3646   3207   3132   3204   3584
noop          3163     2901   3190   3293   3124   3308
deadline      3547     3923   3722   3351   3484   3254
anticipatory  3384     3453   3916   2944   3451   3156

As you can see, the averages are very close -- closer than the "noise" between runs.  As far as I can tell, there is no significant advantage, or even any significant difference, between the various I/O scheduler algorithms.

(It also reinforces what the pgbench man page says: Short runs aren't useful.  Even these two-minute runs have a lot of variability.  Before I turned off AutoVacuum, the variability was more like 50% between runs.)

Craig