Following on from my previous post, I’ve decided to use filebench (Version 1.4.9.1)
for a more structured testing approach. Filebench is easy to work with, as it has already defined several application types (workload) profiles and is easy to install. The workloads can be defined easily (using WML scripting) to mimic any sort of application load on the IO system. I cannot comment on how accurate these workloads are, but they make testing easy :).
The method I’ve used was very simple. Three runs of 60 seconds each, with the default settings for the workload profiles, except for the randomwrite and randomread workloads where I had to reduce the file size to 100 MB. I disabled randomization ( echo 0 > /proc/sys/kernel/randomize_va_space ) as recommended by filebench. Filebench allocated 170 MB of shared memory on all the runs (this appears to be the default).
The results are the average results of the three runs, except for the randomread workload where I only did two runs as the results were very similar. I did not repeat any tests as there was a lot less variation in the results. The results presented below are the IO summary result, rather than the individual operations results.
So without further ado here are the results:
| Workload | varmail | webserver | fileserver | randomwrite | randomread | webproxy | |
| Server | |||||||
| PMSTest (RAID1) | 1.24 MB/s | 6.83 MB/s | 4.20 MB/s | 13.63 MB/s | 89.1 MB/s | 1.50 MB/s | |
| PMSControl | 5.02 MB/s | 3.73 MB/s | 4.93 MB/s | 39.83 MB/s | 88.9 MB/s | 2.33 MB/s | |
The webserver results are somewhat mystifying. The workload consists of opening, reading and closing files, so the results should be fairly similar but for some reason the pmsApp is faster!
The rest of the results are as expected: Writes are significantly slower due to nature of the pmsApp (namely a RAID array across a network link) and reads are comparable.
It is also worth noting that regardless of the results, the test prep phase took longer, sometimes a lot longer, when running off the pmsApp, i.e on PMSTest.
Another great writeup. Thank you very much.
After having a look at filebench personalities it seems that the webserver does mostly reading, it only writes “to a logfile”. The fileserver has more random IO.
Thanks again to manyrootsofallevil
My point was that the results should be fairly similar to each other, i.e. the guest running off the pmsApp compared to the control guest. (I’ve changed the post to make this clearer)
Having re-checked the webserver profile, I’m even more mystified as all it seems to be doing is reading files (apart from writing a log). mmm…
Just thought of a thing that might help improve performance a bit.
In the cluster.conf file change the line:
<fs device="/dev/md0" fstype="ext4" mountpoint="/sharedstorage" name="sharedvol">To:
<fs device="/dev/md0" fstype="ext4" mountpoint="/sharedstorage" name="sharedvol" options="noatime">This will prevent the filesystem from updating inode access times which in turn should speed the access up a bit. Would it be possible to re-run the performance tests with noatime set to see if it changes anything?
Found a small article telling a bit about how iSCSI can be optimized:
http://www.randomboot.org/storage/518-iscsi-performance-tuning.html
I’ve repeated a few of the tests and there does not appear to be any significant changes in results after adding this option, some are faster some are slower, but the average hasn’t changed by much