A wonderful reader of my blog sent me a note (thanks Jess!) about a single line notation in the latest SQL Server release notes. The notes is as follows.
The question was simple. Why would Microsoft add this disclaimer? It was being used as a negative talking point towards SQL Server virtualization, and holding the DBA team back from getting the benefits of virtualization.
The answer is simple at first, but goes a lot deeper than first glance. Any OSE / process running inside a VM will almost always be slower than its bare metal equivalent. The CPU scheduler inside the hypervisor for each operation executed in-guest does have a bit of overhead against the OSE running against a bare metal server with direct access to the compute resources. The same goes for storage queueing.
But… how much slower? That’s the question.
In my experience, when the VM layer is configured and managed properly*, the experienced overhead of this virtualization layer lies well below 0.5%. That’s low enough to barely be able to measure it, let alone feel it. Most production environments that I tune are quite solid under virtualization, and I’ve been able to get them to about 0.2% for well-managed and constructed environments.
*Note: If the VM layer is misconfigured, VMs misaligned with the physical compute resource topology (vNUMA, etc.), or flat out abused with too many VMs actively running on the host, then the vCPU scheduling queues can stack up, and you can start to experience a very significant slowdown of your VMs. It’s not the fault of the hypervisor. It’s the fault of the management of the platform, can be identified very easily, and usually fixed quickly.
The easiest way to identify if vCPU scheduling is causing any significant performance penalties is to look at the scheduling delays directly. If you’re on VMware, read this, and if you’re on Hyper-V, read this.
So, yes, virtualization does add overhead. It can be managed so that it is undetectable for your workload. The benefits of virtualization far outweigh the tiny amount of overhead from running in a VM, though, and all of your SQL Servers should be virtualized at this point!