While investigating sluggish performance on a Windows Server virtual machine that hosts a departmental database, you collect the following hypervisor metrics during a five-minute sample:
CPU Ready: 12-16 %
Co-Stop: 5-7 %
Guest-OS CPU utilization: 20-30 %
Host-wide CPU utilization: 45 %
No memory ballooning, swapping or storage latency is detected. The VM is provisioned with 8 vCPUs on a host that contains 16 physical CPU cores and several other lightly loaded VMs. No CPU limits or reservations are configured.
Based on these findings, which corrective action is MOST likely to restore normal performance for this workload?
Reduce the VM's vCPU count to the minimum required by the workload
Enable hyper-threading on the host to double the logical CPU count
Increase the VM's memory reservation to guarantee physical RAM
CPU Ready values above about 5 % indicate that one or more vCPUs are frequently waiting in the run queue even though physical CPUs are available. A common cause is oversizing-allocating more vCPUs than the workload can actually use. With an 8-vCPU configuration, the scheduler must find idle cores for all vCPUs before the guest can run a thread, increasing Ready and Co-Stop times. Right-sizing the VM to fewer vCPUs reduces scheduling contention and immediately lowers CPU Ready.
Raising memory reservations will not affect CPU-scheduler wait time because no memory contention is present.
Increasing CPU shares can help during genuine contention, but the host still has ample spare capacity; Ready time here stems from co-scheduling, not share weighting.
Enabling hyper-threading may add logical cores, yet it does not correct per-VM oversizing and provides only partial additional throughput.
Therefore, reducing the VM's vCPU count is the most effective fix for this misallocated virtual-resource problem.