Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a small VM ESX 3.0 implementation - mostly test web servers, however there is 1 db server that gets terrible io performance.

Will adding additional virtualized disks in a RAID help performance much?

share|improve this question
add comment

3 Answers

This is typical - VM people often ignore the IO loadout that databases have. Databases often are a bad candidate for shared storage because they need a LOT of IO. Recemmended setup would go inthe direction of running the VM from a shared storage, but the actual database used discs coem from seaprate dedicated LUN.

Not so much that VmWare sucks IO wise, as that the database often has special needs. As an example (Hyper-V, but the same principles apply): * I run a pretty large Hyper-V server with 32gb RAM. * The OS + the virtual images run of 4 disc RAID 10, Velociraptor. performance is OK... EXCEPT: * The SQL Server running there has another 6 (!) discs in a RAID 10 for it's data to meet the dedicated IO load requirements, plus discs for logging.

There is simply no real way to get all under the same RAID properly. Databases typially LOVE IO performance - and a shared setup can not guarnatee those.

So, my advice stands: get some separate discs for the acutal data.

share|improve this answer
add comment

I have no idea what kind of I/O overhead ESX 3.0 has, as it's an outdated product.

Testing against VMware vSphere (4.x) shows that there is just about no overhead at all on I/O intensive applications - as long as you scale your setup correctly.

First of all: RAID performance suffers in VMware on the same basics as every other RAID usage. You can't put several VM's and a heavy I/O VM on the same LUN/Array and expect it to go spiffy.

There are several steps you can do to ensure that your DB gets full performance. Here are the most basic ones:

  1. Improve caching. Add lots and lots of RAM. It's cheap compared to a few years ago.
  2. Separate your DB data and log files on different arrays (spindles - as in disks)
  3. Isolate your DB vm as much as possible. I've heard about extreme conditions where they run a ESX server with a single DB VM on it. This is a costly option though.

I also advise you to find out whats causing your I/O bottleneck before you change configuration.

share|improve this answer
    
"as long as you scale your setup correctly" that's kinda like saying "I'm the smartest man alive- so long as everyones dumber than me" The problem isn't that vsphere can't be made to perform almost as well as bare metal, the problem is that getting it setup to do so in a working, living, vmware infrastructure, can be almost impossible. It takes the right combination of talent, tools nad equiptment to pull it off and just investigating what your options are can be more expensive than simply going native. –  Jim B Aug 2 '10 at 15:29
    
It depends on what you classify as nearly-bare-metal speed. For most businesses out there a 10% decrease in I/O (if such would exist in vSphere) would probably OK compared to the ease of backups, HA, reconfiguration and all the other neat stuff virtualization brings. I also think you're overestimating the knowledge level for someone to get a vSphere enviroment working properly - as there are tons of documentation (including best practices from VMware) out there.. –  pauska Aug 2 '10 at 16:19
add comment

My experience is that regardless of the OS running a database under VMware (or other virtualization) equals to sloooooooooooow I/O. Newer VMware versions improve the situation quite a bit, but it's still not the same than a bare metal OS installation.

share|improve this answer
    
This is simply not true. See my answer. –  pauska Aug 2 '10 at 11:35
    
Actually it is true - as he said, old versions suck, new versions are more ok. –  TomTom Aug 2 '10 at 11:37
    
Erik: Trust me, under VMware ESX 3.0 things WILL get slow I/O-wise if you try some serious database-fu with it. This is especially true if there are several resource hungry VM's humming around. No amount of sacrificed virgins, drinken beer or enjoyed grilled beefs change that. I tried. But, the product is outdated and the later ESX pretty much fixes the problem. –  Janne Pikkarainen Aug 2 '10 at 12:00
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.