Why a virtual machine is slow: the processor, the disk, or overcommit

When a virtual machine slows down, the first reflex is to give it more cores. That usually does nothing, and sometimes makes it worse. The source of the slowness has to be separated first.

Overcommit: when total vCPU exceeds the physical cores

The vCPUs handed out to machines on a server can exceed the number of physical threads. That is normal and usually harmless, because the machines do not all run at once. But if they all load up together they start queueing. Seen from inside the machine the processor looks idle at that moment, while the machine is in fact waiting its turn. Adding cores here lengthens the queue, it does not shorten it.

A single core bottleneck

Some work lands on one core and sticks there. On an eight core machine the total usage can look low while a single core sits at the top. Adding cores changes nothing here; the answer is either splitting the work or a configuration with stronger single core performance.

Waiting on the disk

If the processor graph is calm and the machine is still slow, the place to look is the disk. The server measures separately the time it spends waiting for data. When that value climbs, the problem is not computation but waiting; disk type, cache setting and the other machines sharing the same disk all come into play.

The order to look in

First compare total vCPU against physical threads to see whether there is overcommit, then look at per core load to see whether one core sits at the top, and only then look at disk wait time. All three measurements live on the host side; looking from inside the machine cannot tell these three states apart.