Is a VM with 2 CPUs really faster than one with 4 CPUs?

Our IT created a VM with 2 CPUs allocated rather than the 4 I requested. Their reason is that the VM performs better with 2 CPUs rather than 4 (according to them). The rationale is that the VM hypervisor (VMWare in this case) waits for all the CPUs to be available before engaging any of them. Thus, it takes longer to wait for 4 rather than 2 CPUs.

Does this statement make sense?

Solution 1:

This used to be true, but is no longer exclusively true.

What they are referring to is Strict Co-Scheduling.

Most important of all, while in the strict co-scheduling algorithm, the existence of a lagging vCPU causes the entire virtual machine to be co-stopped. In the relaxed co-scheduling algorithm, a leading vCPU decides whether it should co-stop itself based on the skew against the slowest sibling vCPU

Now, if the host only has 4 threads, then you'd be silly to allocate all of them. If it has two processors and 4 threads per processor, then you might not want to allocate all of the contents of a single processor, as your hypervisor should try to keep vCPUs on the same NUMA node to make memory access faster, and you're making this job more difficult by allocating a whole socket to a single VM (See page 12 of that PDF above).

So there are scenarios where fewer vCPUs can perform better than more, but it's not true 100% of the time.

All that said and done, I very rarely allocate more than 3 vCPUs per guest. Everyone gets 2 by default, 3 if it's a heavy workload, and 4 for things like SQL Servers or really heavy batch processing VMs, or a terminal server with a lot of users.

Solution 2:

This largely depends on the underlying hypervisor and the admins who run it, let me explain:

1. It's bad practice to just arbitrarily give you 4 CPU's just because you requested it. Generally speaking, you think you need 4; but resource monitoring says you only need 1.
2. VMware ESXi for example requires locking all pCPUs when a vCPU makes a request for CPU resources; so on this hypervisor it is bad for performance. KVM doesn't do locking like ESXi does; it uses the underlying kernel scheduler, but still in the long run can create CPU contention.
3. If you're building systems from the start with 4 CPU's you aren't really scaling out, but up (which is bad practice especially on VMs). You may want to check into how you're architecting whatever it is you're working on so that it can be built to scale to today's modern cloud infrastructures.

What can you learn from this? Always create VMs with minimal resources and increase as needed. Always scale out instead of up and you'll be able to run your app anywhere.

Because of the locking that can be experienced with the hypervisor, it is indeed true that 2 CPU's can be faster than 4 CPUs.