Richard Mahlerwein wrote: > If I recall correctly from ESX (well, VI) training*, there may be a minor > scheduling issue affecting things here. If you set up the VM with 4 > processors, ESX schedules time on the CPU only when there's 4 things to > execute (well, there's another time period it also uses, so even a single > thread will get run eventually, but anyway...). The physical instance will > run one thread immediately even if there's nothing else waiting, whereas the > VM will NOT execute a single thread necessarily immediately. I would retry > using perhaps -j8 or even -j12 to make sure the 4 CPUs see plenty of work to > do and see if the numbers don't slide closer to one another. > > For what it's worth, if there were a raw LUN available and made available to > the VM, the disk performance of that LUN should very nearly match native > performance, because it IS native performance. VMWare (if I understood right > in the first place and remember correctly as well, I supposed I should * this > as well. :) ) doesn't add anything to slow that down. Plugging in a USB > drive to the Host and making it available to the guest would also be at > native USB/drive speeds, assuming you can do that (I've never tried to use > USB drives on our blade center!).
I've isolated the problem to the SATA RAID system (or subsystem). Booting from CD/USB key and running a wide array of bench tests, I can not read from the RAID setup faster than 10MBps. Regardless of anything else, this is my priority. RAID 0 is the only config where I can read faster than ~7MBps. The board does not have any standard IDE interfaces, and I don't have any PCIe-IDE cards that aren't in use, so I can't really bypass the HP RAID card. I will however slap a 200GB USB drive against the box, and see if I can get faster performance from USB than I can the native SATA setup. FWIW, I do have the battery backed cache installed... Steve
smime.p7s
Description: S/MIME Cryptographic Signature
