Monday, November 28, 2005
ORION Numbers
When I noticed Jeff Moss' blog about Orion, I realised it could be a useful tool to validate the performance of different i/o subsystems that I want to test for the parallel execution paper I'm working on.
As I've still only got two hard disk drives installed in the server, I decided the best bet was to keep one drive for boot, Linux, Oracle software and an initial starter database and keep the second drive free for the single-disk version of the test database. I was able to create a raw device mapping for that using information found here
I think I found Orion a bit more straightforward to install than Jeff. I already had libaio installed as part of the White Box Linux 2.6.9 installation and maybe it helped that I was installing straight on to a couple of different physical servers, rather than virtual machines. The only minor problem I had was a consequence of my original intention to create a database on the second disk. I had a filesystem mounted on the device at first so Orion couldn't aquire the device properly for the test. I simply unmounted the filesystem and everything worked fine.
And here's the command I used
And my results were
Next I created a dw.lun for a more advanced test geared towards larger reads (as Jeff did). Obviously my results will be quite different because I wasn't using two drives, but here's the command and the results.
Without analysing exactly what is going on with the i/o subsystem, this utility lets you carry out a quick sanity check and if the numbers don't make sense, it's a sign you should start digging deeper. For example, I have both disks connected to the SCSI backplane, but that's connected to an older legacy SCSI port that I can boot from, rather than the Intel RAID card. It'll be interested to see what the relative performance of that is when I get the drives rearranged.
For comparison, here are the Simple test results on the single Pentium 550 with a single 20Gb IDE drive. First I needed a different simple.lun
And my results were
So it's immediately obvious that the single SCSI drive in the ISP4400 outperforms the single IDE drive in the PC. Rather than just guessing at the relative performance of the different servers, Orion at least gives me a guideline. There are plenty of different options too so you could carry out much more detailed tests.
Based on my experience I think this tool could become very popular in the work place. There are other tools out there that do a similar job - I've certainly used one of Jonathan Lewis' in the past - but this has a good range of functionality and surprisingly good documentation for beta software. Hopefully Oracle will make it available on other Operating Systems soon (the ones we're more likely to use at work, Solaris for example). I imagine a brilliant future when it becomes so ubiquitious that DBAs can prove to storage administrators that something isn't right ;-) (I know there are ways of doing that already, but if we can say - 'Here's this tool from Oracle ....')
Thanks to Jeff for drawing my attention to this - one up for the blogosphere!
As I've still only got two hard disk drives installed in the server, I decided the best bet was to keep one drive for boot, Linux, Oracle software and an initial starter database and keep the second drive free for the single-disk version of the test database. I was able to create a raw device mapping for that using information found here
raw /dev/raw/raw1 /dev/sdbI think I found Orion a bit more straightforward to install than Jeff. I already had libaio installed as part of the White Box Linux 2.6.9 installation and maybe it helped that I was installing straight on to a couple of different physical servers, rather than virtual machines. The only minor problem I had was a consequence of my original intention to create a database on the second disk. I had a filesystem mounted on the device at first so Orion couldn't aquire the device properly for the test. I simply unmounted the filesystem and everything worked fine.
/dev/raw/raw1And here's the command I used
./orion -run simple -testname simple -num_disks 1 -verboseAnd my results were
Maximum Large MBPS=25.65 @ Small=0 and Large=2
Maximum Small IOPS=138 @ Small=4 and Large=0
Maximum Small Latency=8.92 @ Small=1 and Large=0
Next I created a dw.lun for a more advanced test geared towards larger reads (as Jeff did). Obviously my results will be quite different because I wasn't using two drives, but here's the command and the results.
./orion -run advanced -testname dw -num_disks 1 -matrix point -num_small 0 -num_large 4 -type seq -num_streamIO 2 -cache_size 0 -verbose
Maximum Large MBPS=27.85 @ Small=0 and Large=4
Without analysing exactly what is going on with the i/o subsystem, this utility lets you carry out a quick sanity check and if the numbers don't make sense, it's a sign you should start digging deeper. For example, I have both disks connected to the SCSI backplane, but that's connected to an older legacy SCSI port that I can boot from, rather than the Intel RAID card. It'll be interested to see what the relative performance of that is when I get the drives rearranged.
For comparison, here are the Simple test results on the single Pentium 550 with a single 20Gb IDE drive. First I needed a different simple.lun
/dev/VolGroup00/LogVol00
But then the same command
./orion -run simple -testname simple -num_disks 1 -verboseAnd my results were
Maximum Large MBPS=14.46 @ Small=0 and Large=1
Maximum Small IOPS=46 @ Small=5 and Large=0
Maximum Small Latency=22.96 @ Small=1 and Large=0
So it's immediately obvious that the single SCSI drive in the ISP4400 outperforms the single IDE drive in the PC. Rather than just guessing at the relative performance of the different servers, Orion at least gives me a guideline. There are plenty of different options too so you could carry out much more detailed tests.
Based on my experience I think this tool could become very popular in the work place. There are other tools out there that do a similar job - I've certainly used one of Jonathan Lewis' in the past - but this has a good range of functionality and surprisingly good documentation for beta software. Hopefully Oracle will make it available on other Operating Systems soon (the ones we're more likely to use at work, Solaris for example). I imagine a brilliant future when it becomes so ubiquitious that DBAs can prove to storage administrators that something isn't right ;-) (I know there are ways of doing that already, but if we can say - 'Here's this tool from Oracle ....')
Thanks to Jeff for drawing my attention to this - one up for the blogosphere!
