Seeker io benchmark on small EC2

Frederic posted an interesting link to the seeker io script in the sysbench fileio vs small EC2 article.

He was concerned that the seeker was showing difference numbers to sysbench fileio, especially on the /mnt mountpoint.

I read the thread and there was another comment made concerning how Xen could use a sparse file image to improve the io performance. I tested that theory out and found as soon as I created a reasonable sized file on /mnt, the performance dropped significantly to less than 20% of the empty mountpoint performance.

I appreciate the feedback I receive via comments. Most of the feedback I have derive purely from Google web analytics and sitemap tools.

Results:



[root@domU-12-31-35-00-04-61 ~]# sudo hdparm -t /dev/sda1

/dev/sda1:
Timing buffered disk reads: 216 MB in 3.01 seconds = 71.68 MB/sec
[root@domU-12-31-35-00-04-61 ~]# sudo hdparm -t /dev/sda2

/dev/sda2:
Timing buffered disk reads: 380 MB in 3.00 seconds = 126.51 MB/sec


[root@domU-12-31-35-00-04-61 ~]# ./seeker /dev/sda1
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda1 [1025MB], wait 30 seconds..............................
Results: 278 seeks/second, 3.60 ms random access time

./seeker /dev/sda2

Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda2 [152688MB], wait 30 seconds..............................
Results: 5741 seeks/second, 0.17 ms random access time

Add a file to /mnt to test the sparse Xen image idea

dd if=/dev/zero of=/mnt/zerofile bs=1024M

[root@domU-12-31-35-00-04-61 mnt]# ls -l
total 7347232
drwx------ 2 root root 16384 Mar 16 12:38 lost+found
-rw-r--r-- 1 root root 710 Mar 16 23:37 randomfile
-rw-r--r-- 1 root root 7516192768 Mar 16 23:44 zerofile
[root@domU-12-31-35-00-04-61 mnt]# cd
[root@domU-12-31-35-00-04-61 ~]# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 1032056 885984 93592 91% /
/dev/sda2 153899044 7539888 138541532 6% /mnt
[root@domU-12-31-35-00-04-61 ~]# ./seeker /dev/sda2
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda2 [152688MB], wait 30 seconds.............................
Results: 1101 seeks/second, 0.91 ms random access time
[root@domU-12-31-35-00-04-61 ~]# ./seeker /dev/sda2
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda2 [152688MB], wait 30 seconds......................
Results: 582 seeks/second, 1.72 ms random access time
[root@domU-12-31-35-00-04-61 ~]# ./seeker /dev/sda2
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda2 [152688MB], wait 30 seconds.....................
Results: 177 seeks/second, 5.62 ms random access time
[root@domU-12-31-35-00-04-61 ~]# ./seeker /dev/sda2
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda2 [152688MB], wait 30 seconds.........................
Results: 881 seeks/second, 1.13 ms random access time
[root@domU-12-31-35-00-04-61 ~]# w
23:50:30 up 4:07, 1 user, load average: 0.62, 3.77, 3.39
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root ttyp0 203-19-70-133.pe 19:47 0.00s 0.01s 0.00s w
[root@domU-12-31-35-00-04-61 ~]# ./seeker /dev/sda2
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda2 [152688MB], wait 30 seconds....................
Results: 355 seeks/second, 2.82 ms random access time

Advertisements

One thought on “Seeker io benchmark on small EC2

  1. Correct me if I’m wrong, but there isn’t a small difference between the sysbench test and the seeker one. They are completely in opposition.Sysbenching the /mnt mount point shows that /mnt is far slower than the root partition.The seeker executable shows that the /mnt points is a lot faster.So which test should I believe ?I plan to use the large, x-large amazon instance to host a master-slave replication installation. Due to the limitation in size of the root partition (10GB), I need to use /dev/sdb (data) and /dev/sdc (logs) for that.Is this a good or a bad solution based on the number you (very kindly) share with us.

Comments are closed.