7

We had a VMWare VM at work with two cores allocated to it that ran a pretty heinous process in IIS. Under load the process was maxing out the CPU usage on both cores, so we asked our system engineers to present the other two cores of the physical processor to the VM. The engineer immediately said that this would not improve performance at all, but would make the VM perform worse. He dismissed the reason for his statement had anything to do with the ESX server's capacity, or resource contention.

That statement didn't make much sense to me, and I'm wondering how what the engineer said could be true. Are there actually cases where four cores presented to a VM would cause worse performance than two cores on the same physical hardware? Let's assume an ideal situation where there's only one VM on the host server, so nothing is being shared with other OS instances.

I believe the physical server had a single quad core processor, and was most likely hosting multiple VMs. I don't really know what version of ESX was running on the host, nor do I know with certainty what the physical processor config was, but from within the VM I had access to, I saw two 3.33 GHz AMD processors.

In the end, I never got to test the engineer's assertion out because (while we were trying to get the VM upgraded) we were able to optimize the process and reduce it's CPU consumption, and 2) we ended up migrating to a different VM on another ESX server which had four cores presented to it.

Improve this question

4 Answers 4

Reset to default
9

I'll chime in here and say that what your engineer was likely talking about is the fact that a VM with multiple vCPU's has a distinct disadvantage when scheduling CPU cycles. A 1 vCPU VM can execute instructions as soon as a single core is available. If a VM has 4 vCPU's, then it literally cannot execute any instructions until 4 cores are available.

If your box has a decent number of VM's on it, this definitely could slow you down b/c your VM will have to wait in line for 4 cores to free up. It could also slow the other VM's down because it will have all 4 cores tied up at once.

I don't want to get into Hyper-Threading and all that, but above is a simple explanation of what I think your guy might have been referring to. Although he may not have done the best job explaining it.

Improve this answer
6
  • 4
    What you are referring to is called strick co-scheduling in VMware terminology and it isn't completely accurate in recent versions of VMware. Scheduling multiple vCPU's is harder (and Rex's answer summarizes most of the reasons) but absolutely strict co-scheduling has not been constraint since ESX 3.5. There are still restrictions but some drift between vCPU's is allowed which makes scheduling a lot less of an issue than it was. You are almost certainly correct that this was what the engineer in question was thinking though.
    – Helvick
    Jan 5, 2011 at 23:19
  • Thanks for the clarification. It just sounded like that was what the guy meant.
    – B. Riley
    Jan 6, 2011 at 1:16
  • @B. Riley - That's a great insight; some of what you mention jibes with some things our engineer said. But would you expect the performance to actually be worse than with two cores? I can see it being less than optimal, but I have a hard time believing it would not beat out two cores. Essentially, his blanket statement was that if I give you four cores, your VM will run worse than it does with two, and when asked if it was due to contention, he said contention had nothing to do with it.
    – arcain
    Jan 6, 2011 at 3:53
  • @arcain The issue is that in the old days the server would have to wait for a time slice where all four processors were available. You are less likely to find all four available at the same time than merely finding two available at the same time -- especially if you are only running on a 4-core base system. So a system with two vcpus would find timeslices more frequently, meaning they'd get more overall work done.
    – David Mackintosh
    Jan 6, 2011 at 4:41
  • @arcain - Going off the assumption that your application is multi-threaded, and that you are running ESX 3 or 4x, I would not expect a performance decrease. That said, I would also not expect a significant increase either. From what I have seen, the effect of multiple vCPU's is marginal. That is a testament to VMware's scheduling algorithm, and just how well they allocate resources in a multi-tenant environment. It really is THAT good.
    – B. Riley
    Jan 6, 2011 at 14:13
6

Best practice for vSphere per VMWare is to use as few virtual CPU's as possible. If the applications aren't built for SMP applications, it can have a negative impact if you assign multiple vCPU's to the guest.

Even if some vCPUs are not used, configuring virtual machines with them still imposes some small resource requirements on ESX: * Unused vCPUs still consume timer interrupts. * Maintaining a consistent memory view among multiple vCPUs consumes resources. * Some older guest operating systems execute idle loops on unused vCPUs, thereby consuming resources that might otherwise be available for other uses (other virtual machines, the VMkernel, the console, etc.). * The guest scheduler might migrate a single-threaded workload amongst multiple vCPUs, thereby losing cache locality.

It's possible that if the host was maxing out all the physical CPU cycles, it could cause other performance issues since the host starts bogging down which, in turn, causes all the guests to start bogging down.

edit: Your engineer should have at least been willing to test.

on reading your post again, you said that it only had 1 quad core CPU.. if that's the case, I would probably go with your engineer and say that assigning all 4 physical CPU's to one guest is a bad idea. The overhead on the host to manage all 4 vCPU's when there are only 4 physical cores would bring down overall performance.

The problem is that adding 4 vCPU's on the gust when the host only has 4 cores total is you are assigning all your physical CPU resources to one machine. The overhead in having the hypervisor managing all 4 vCPU's will end up taking resources away and your realized gains would most likely be minimal

Improve this answer
4
  • Alright, that makes sense, but have you heard of performance actually be degraded by adding more CPUs to a VM just by itself -- unshared? The engineer immediately said the performance would be degraded by adding more CPUs without asking if the process was multithreaded (which it was).
    – arcain
    Jan 5, 2011 at 6:30
  • Normally, no. Unless I was feeling unnaturally ornery (BOFH like) I wouldn't immediately say that it would cause worse performance given the information you've presented. There, of course, may be other issues at play which may be why he jumped to that conclusion.
    – Rex
    Jan 5, 2011 at 6:36
  • changed my tune after reading your post over again.. edit'ed my answer to reflect new thoughts.
    – Rex
    Jan 5, 2011 at 6:45
  • So, I think I'm piecing this together. From what B. Riley and Helvick said, I'm guessing that our engineer was referring to the performance penalty that could be incurred if the ESX server was subject to strict coscheduling. From what you mention it looks like the performance would be less than optimal if four cores were assigned, but I'm thinking it would still exceed that of a two core VM. Is that the drift I'm picking up?
    – arcain
    Jan 6, 2011 at 4:00
3

A rule of thumb that I picked up so far, is to always have less virtual cpu assigned to a single vm than are physically present in the host.

One resaon for this beeing (befor esxi) that the console vm was allways running. for scheduling resaons you would only get cpu cycles to the vm when the amount of virtual cpus were idle at the same time. otherwise your "cpu wait time" will increase

So with a quadcore cpu in the host i would only assign max. 2 cpus to a vm.

Improve this answer
1
  • 1
    even in ESXi, the hypervisor still is busy scheduling vCPU and managing memory.. the service console was not the hypervisor. Service console was for hypervisor management - not for the actual work the hypervisor did.
    – Rex
    Jan 5, 2011 at 13:58
0

It depends on what else is using those other cores. If the cores are idle then yes adding those cores to your VM would improve performance (I'm assuming that the application running on your VM is multi-threaded and capable of using all 4 cores). If the cores are busy then it probably won't help, or at least not as much as one would think.

Improve this answer
3
  • So you are saying that his assertion would be false? That there is not a case where adding more processors to a VM should immediately degrade performance? Assume that the VM isn't shared.
    – arcain
    Jan 5, 2011 at 6:34
  • Your engineer should have at least been willing to test. But The problem is that adding 4 vCPU's on the gust when the host only has 4 cores total is you are assigning all your physical CPU resources to one machine. The overhead in having the hypervisor managing all 4 vCPU's will end up taking resources away and your realized gains would most likely be minimal.
    – Rex
    Jan 5, 2011 at 13:59
  • You shouldn't see performance get worse. At worse performance should stay the same, but generally you would see some sort of improvement.
    – mrdenny
    Jan 5, 2011 at 19:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .