Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
add comment

4 Answers

up vote 6 down vote accepted

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.

share|improve this answer
3  
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 '11 at 23:19
    
Thanks for the clarification. It just sounded like that was what the guy meant. –  B. Riley Jan 6 '11 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 '11 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 '11 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 '11 at 14:13
show 1 more comment

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

share|improve this answer
    
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 '11 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 '11 at 6:36
    
changed my tune after reading your post over again.. edit'ed my answer to reflect new thoughts. –  Rex Jan 5 '11 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 '11 at 4:00
add comment

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.

share|improve this answer
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 '11 at 13:58
add comment

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.

share|improve this answer
    
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 '11 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 '11 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 '11 at 19:04
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.