The Late Great Virtual CPU Debate

Do you ever have the situation where you have a sluggish virtual machine (VM) and in trying to find the bottleneck, you raise the number of vCPUs? Did it work? If your VM experiences a slowdown, then the problem is the extra vCPU(s). It's counterintuitive to see this occur but it's a real phenomenon. To clarify, you might experience a performance hit by adding vCPUs to a VM. Crazy, yes, but there are some good reasons for it.

You also want to be careful of using multiple vCPUs and then moving back to a single vCPU. Some operating systems don't do well with that change. Windows Server 2003 being one of them.

So, if using multiple vCPUs might cause a performance slowdown, why would VMware and other vendors support them?

Good question.

The answer is simple. You need multiple vCPUs if your application running on the VM is multi-threaded and can use multiple processors. A good example is database servers. MS SQL Server, Oracle and others.

But, still why should performance take a hit by giving a VM more resources? The answer has to do with how CPU power is scheduled and parsed out to VMs. If you've given a VM four vCPUs, then that VM wants four free cores on which to run its processes. Finding four free cores at once might leave your VM a little hungry and hence the poor performance. Now, that's a great simplification of the situation but if you'd like an in-depth analysis of CPU performance, time slices, cores and more, pick up a good book on performance tuning.

If your application is single-threaded, like most legacy applications, do yourself a favor and use a single vCPU. And, find other ways to mitigate the performance problems. Here are some performance optimizations that don't involve vCPU number editing.

• Add RAM to your VM - This depends on your workload type. If it's RAM-intensive, increase the RAM. But, don't be wasteful with memory resources, allocate what's needed, monitor and adjust.
• Separate your virtual disks onto different LUNs - You can place virtual disks on different LUNs. You'll have to monitor your disk performance closely to decide where to relocate additional disks. An excellent method of moving VMDK files is to use the LostCreation's SV Motion VI Center plug-in.
• Adjust your pagefiles or swap space to better handle the workload - On Windows systems, set your pagefile to a static size for best performance (Twice RAM is a good size) and split up the pagefiles onto different disks (VMDKs), if possible. For Linux systems, place swap space into a separate VMDK, if possible.
• Don't use Screensavers. You don't need them on VMs.
• Add additional vCPUs only if your vCPU is sustaining high usage (90%-100%). Occasional bursts are to be expected, especially on Windows where you can peg the CPU by dragging a Window around the screen. In other words, don't fret over periodic high usage. It's a computer. It's supposed to process.
• Don't oversubscribe CPU - One vCPU translates to one physical processor core. You can throttle CPU usage, and should for most systems.
• Install VMware Tools - Install the Tools to gain more performance out of your VMs through enhanced network, video, mouse and other drivers.

There are other enhancements that you can try but these will get you started in the right direction.

So, the main point you should take away from this is to use single vCPUs for all VMs unless you have an extremely compelling reason to use more. And, there are very few compelling reasons to do so. My best advice is to experiment in a test environment first and measure performance closely. Of course, no test environment can fully emulate production and nuances that occur there with human users.

Write back and discuss your experiences with using multiple vCPUs and for which workloads you use them. I'm especially interested in your experiences with multiple VMs running in production with 4 or more vCPUs.