Virtualization Performance – or lack thereof
People always seem very shocked when I suggest that virtualization comes with a very substantial performance penalty even when virtualization hardware extensions are used. Concerningly, this surprise often comes from people who have already either committed their organization’s IT infrastructure to virtualization, or have made firm plans to do so. The only thing I can conclude in these cases, unbelievable as it may appear, is that they haven’t done any performance testing of their own to assess the solution they are planning to adopt.
So I decided to document some basic performance tests that show just how substantial the performance hit of virtualization is.
Core2 Quad 3.2GHz
8GB of RAM
2x500GB 7200rpm SATA DM RAID1 for the main system
1x250GB 7200rpm SATA for testing
Virtual Test Configuration (VMware Player 4.0.4, Xen 4.1.2 (PV and HVM), KVM (RHEL6), VirtualBox 4.1.18):
CPU Cores: 4 (all)
Disk: System booting off the 2×500 RAID1. Raw 250GB SATA disk passed to the VM.
Disk write caching was enabled in the VMware configuration. You may think that this unfairly gives the VM configuration an advantage, but as you will see from the results, even with this “cheat”, the performance is still very disappointing compared to bare metal. In any case, the amount of disk I/O is negligible – the caches and the working set always fit into memory.
Physical Test Configuration:
CPU Cores: 4 (all)
RAM: 6GB (limited using mem=6G boot parameter)
Disk: Booting directly off the same 250GB SATA disk used for VM testing, with the same kernel and configuration.
The test performed is the compile of the vanilla 22.214.171.124 Linux kernel. This is the script used for testing:
#!/bin/bash echo Cleaning... make clean > /dev/null 2>&1 make mrproper > /dev/null 2>&1 sync echo 3 > /proc/sys/vm/drop_caches echo Configuring... make allmodconfig > /dev/null 2>&1 echo Syncing... sync find . -type f -print0 | xargs --null cat > /dev/null echo "Timing build..." time (make -j16 all > /dev/null 2>&1)
The source tree is cleaned and all caches dropped. The allmodconfig configuration is used to get some degree of testing of disk I/O by creating the maximum number of files. Caches are then primed by pre-loading all the source files. This is done in order to more accurately measure the CPU and RAM subsystems without bottlenecking on disk I/O. The CPU in the system has 4 cores, and 16 build threads are used to ensure the CPU and memory I/O are saturated, but without causing enough memory pressure to cause swapping.
On the host and in the guest, all unnecessary services and processes were stopped (especially crond which could theoretically cause additional load on the system that would distort the results).
All tests were carried out 3 times in a row, and the best result for each is considered here (the differences between the runs were minimal).
This is very much a redneck, brute-force test. There isn’t much finesse to it. But I like tests like this because they cannot be cheated with the sort of smoke and mirrors illusions that virtualization software is very good at applying.
|Xen 4.1.2 (PV):||1,316.984s||(79.16%)|
|VMware ESXi 5.0.0:||1,361.321s||(76.58%)|
|VMware Player 5.0.0:||1,478.732s||(70.50%)|
|VMware Player 4.0.4:||1,520.023s||(68.59%)|
|Xen 4.1.2 (HVM):||2,839.442s||(36.72%)|
Note: No, this is not a typo – VirtualBox really is that bad.
To make this difference easier to visualise, here it is on graphs:
To give a better idea of relative performance, here it is in % points, with bare metal being 100%.
The difference is substantial even with the least poorly performing hypervisor. Virtualization performance is over a 5th (21%) down with paravirtualized Xen down compared to bare metal, and nearly a quarter (24%) lower than bare metal with VMware ESXi, and even worse with KVM. Or if you prefer to look at it the other way around, bare metal is more than a quarter as fast again (26.32%) as the best performing hypervisor on the same hardware.
Don’t get me wrong – virtualization is handy for all sorts of low-performance tasks. In cases where it is used to consolidate a number of mostly idle systems into one mostly idle system, it brings clear benefits. (Except maybe in the case of VirtualBox – the performance there is just too appalling for anything, and HVM Xen is pretty poor, too.) But for uses where performance is important, thoughts of virtualizing need to undergo a serious reality check. Even if your system is designed to scale completely horizontally, requiring 26%+ of extra hardware (best case scenario, it could be a lot worse depending on which hypervisor you use) is likely to put a significant strain on your budget and running costs.
Note: It is worth stressing that these tests are carried out on hardware with VT-x, and support for this is enabled and used for all the tested hypervisors. So the results here are based on optimal hardware support.
My findings here are not an isolated case – here is an excellent research paper on virtualization performance overheads.