I've done a multitude of benchmarks using various 2.6 IO schedulers. Hands down the Deadline I/O scheduler is the best for INNODB traffic or RANDOM IO. I use to have all this benchmark information in excel worksheets, but lost it when I left Friendster.
Here is how to figure out what IO scheduler your using in Linux 2.6
dmesg |grep -i sched
In most cases your probibly set up to use the cfq io scheduler. Change it to deadline in your PXE, lilo, or grub settings.
For example:
# For booting GNU/Hurd
title GNU/Hurd
root (hd0,0)
kernel /boot/gnumach.gz root=hd0s1
module /boot/serverboot.gz
append to it
kernel /boot/wtfe root=wtfe elevator=deadline
Thanks Peter N. for the linux config info!
5 comments:
But when do they matter? I know they must matter, but have not measured much of a difference for Linux 2.6.11, 2 disks, SW RAID 0, ext2 and direct or buffered IO.
My advice is to switch by default to deadline. I've benchmarked it as well and deadline is often coming out on top for random IO which is what most people are using.
I wish there was a way to tell if a machine was using the deadline schedule OTHER than 'dmesg' .
It needs to be in /proc . I'd like to write a script that sends off an email if a machine isn't running deadline.
If you have a recent 2.6 kernel you can get/set the io scheduler through:
$ cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq
this machine is running deadline.
To set cfq:
$ echo "cfq" > /sys/block/sda/queue/scheduler
Easy, no ?
interesting , i will check if io scheduler has some
effect on firebird databases too
i saw some redhat benchmarks with oracle and seems that io schedulers do have some performance gain (that is scheduler's sole raison d'être after all )
some related papers
http://www.google.com/search?q=linux+2.6+i%2Fo+schedule
ps: i was really interesting into this because we have one raid-5 setup and one of the drives failed and when adding an new drive to the
raid soft array , the io speed was very poor (1M reconstruction speed) and killed the server (booted in 1 hour), also we had an mysql 5.1 instance with gigs of data that crashed the centos box when updating/reconstructing some table (4G of ram , athlonX2 and raid5 setup )
I couldn't even press ctrl-alt-del or even sysrq keys (no console error or kernel panik)
I call it blank sceen of death (no video output)
it might be related to ACPI or freq scaling but now we replaced with another box (same specs)
and worked
How does the anticipatory scheduler fare in your benchmark? Everything I can find seems to be giving the win to anticipatory over deadline: but none of the articles specifically address database use.
Post a Comment