Hi PacketRacer,
thanks for the information - it's a great starting point.
I understand that this is not an ideal setup for an Oracle database, its not for production use but to test performance when we make changes to our software. Even though the performance is not as good as it could be using other configurations, the performance is isolated from the rest of our network so only changes that we make to our software will affect it - that's the plan and it worked well on the old hardware. We bought new hardware so that we could scale up the tests, but running the old tests on the new hardware produced terrible results - so we need to work out why that is before we move on.
Note that it's READ I/O where the performance is particularly bad, writing (out of our regular performance tests) seems to be similar to the old hardware.
1) Hardware - Old machine had 256MB Battery backed cache, the new machine had 256 MB without battery (ordering mistake), we've just upgraded this to 1GB cache with battery. No significant change to the results at 25% read 75% write. I've just set it to 75% Read 25 % Write with no significant changes to results either. Reading still slow, writing same as the old hardware.
BIOS settings and those of the Smart Array Controller have been checked.
2) The VM we're using to test performance has been cloned from the old hardware onto the new hardware, so it's settings are identical on both servers. Same memory and CPU allocation, no limits set, the server is not running out of resources either, no VM is taking more than its allocated share and there is still spare CPU (less than 50% peak usage) and memory 2GB from 32GB totally free.
3) Do you mean the OS inside the VM or the ESX Installation itself? The OS inside the VM all settings are the same (clone) and for ESX itself both are a standard install of ESX 3.5 update 5.
I'd love to read the paper, but there was no link?
4) orion command we're using: ./orion_linux_x86-64 -run simple -testname sdd -num_disks 1
We're running the same command on both machines, so it should give similar output (even if it is not the ideal test command to use) - is there a better command that I could use (one that does read only tests).
My big concern here is that new hardware that is supposed to have better performance (more memory, faster CPU, faster disks, more cache) is actually performing worse under an Oracle load.
Once we've nailed down what is causing this performance hit on the new machine, then we'll do some more tuning based on your suggestions to try and get even more performance out of it. But first we need to find out why read times on this new hardware are so much slower than on the old hardware.
Thanks for your input though. Any further help is appreciated.
Jack...
