The Late Great Virtual CPU Debate

The Late Great Virtual CPU Debate

Summary: Using multiple vCPUs can decrease VM performance. While that concept is counterintuitive, it makes sense, if you think about how CPU resources are doled out.

SHARE:

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.

Topics: Processors, CXO, Emerging Tech, Hardware, Virtualization, IT Employment

About

Kenneth 'Ken' Hess is a full-time Windows and Linux system administrator with 20 years of experience with Mac, Linux, UNIX, and Windows systems in large multi-data center environments.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

6 comments
Log in or register to join the discussion
  • RE: The Late Great Virtual CPU Debate

    This article oversimplifies everything to the point that some people will do more harm than good with it. In the past I've seen many people take "general case" ideas like these and implement them without knowing the full implications, causing more problems than they solved. There's no substitute for good performance analysis - I suggest that anyone reading this leave this analysis to the professionals.

    Managing performance in a virtual infrastructure is similar to managing performance in the "time sharing" world. Someone who did performance management on IBM mainframes, DEC VAX and Alpha servers running VMS, etc., would probably have some worthwhile experience here.

    Performance problems can be caused by many different things depending on your workloads and the available resources to service them. Shared resources can provide much better return on investment, but they require a bit more planning and expertise to manage to business expectations.

    The suggestions given above may or may not be valid depending on the circumstances - e.g., even oversubscribing CPU could be a valid business decision as long as the implications are acceptable - and most managers probably won't understand that.
    nobodynowherezz
    • RE: The Late Great Virtual CPU Debate

      @JeffLS

      Not sure where you're getting your information. The guidelines given here are from experience and from VMware itself.
      You should NEVER oversubscribe CPU. NEVER. If you do, you're going to choke your other VMs. Just because it's possible to do something doesn't mean you should.
      And, performance doesn't have to be measured by some "performance guru." I have worked in Capacity and Performance for very large companies so I know what I'm talking about. There are some great performance packages out there and it doesn't take a guru to discern red from yellow from green, when looking at performance numbers. Following the guidelines won't cause you problems. It will solve them.
      khess
    • Message has been deleted.

      filhomarques
  • My recomendation: Put as many vCPUs to your VMs as your server has..

    It's better to leave the thread management for the whole server to the host's CPUs. To limit VMs performance manually, doesn't seems to be a good strategy unless you have some software installed on a VM that doesn't work well and maybe It has a infinite loop or something or maybe a realtime priority process (in this case you should not use a VM to run this program as CPU availability is not granted)
    jsapaj
  • RE: The Late Great Virtual CPU Debate

    We operate VSphere in an enterprise-like cloud computing service and have not noticed the behaviors you are speaking of. In fact, our customers say that 1VCPU performs like 1 core on their desktop PC, 2 performs like two, etc.: in other words, our VMWare cloud has predictable performance (assuming 1 VCPU is set to be equal to 1 core, which is not always the default for cloud services.) On the desktop under VMWare Fusion, however, I have noticed some of what you're talking about happening - but only on older versions of VMWare.
    krauskopf
  • MY CPU checklist

    I have a standard CPU checklist for very large database servers. Such as : <br>1)How fast is each physical core?<br>2)Is the hypervisor placing a limit on CPU speed? <br>3)Is there throttling? <br><br>And a whole bunch of either items.check http://www.sqlserver-dba.com/2011/04/virtualization-and-database-servers.html <br>Particuarly for database servers - administrators should do careful research. There is significant management pressure to move from Physical to VM, measuring is important
    jackvamvas