Is a VM with 2 CPUs really faster than one with 4 CPUs? – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.
But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about windows, windows-server-2008, virtual-machines, , .
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?
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.
This largely depends on the underlying hypervisor and the admins who run it, let me explain:
- 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.
- 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.
- 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.
Yes, the statement makes sense in general. However, it’s something you should test for your exact configuration and workload though. Sometimes more CPUs is better if you can actually take advantage of them. However, if you don’t actually have that much parallelism, a VM configured with less CPUs will often perform slightly better as it avoids slowdowns due to CPU Ready State pauses.
I’ve reduced the vCPUs on a number of our VMs and have seen an improve on throughput on the majority. A handful got worse and needed to be bumped up on vCPU count.