vSphere vCPU oversizing: why adding vCPUs made the VM slower

You gave the database VM 16 vCPUs because it was slow at 8. Now it is slower. Host CPU sits at 65%. Guest OS reports 20% utilization. Nothing in the usual dashboards explains the degradation.

This is the vCPU oversizing spiral. Adding vCPUs to a VM that does not need them does not add capacity. It adds scheduling overhead. The ESXi CPU scheduler uses relaxed co-scheduling for multi-vCPU VMs, which means it must find enough simultaneously available physical CPUs to co-schedule a VM’s vCPUs together. The more vCPUs you give a VM, the harder that search becomes, and the longer each vCPU spends in the READY state before it can execute.

The guest OS cannot see this wait. From inside the VM, processes run more slowly, but CPU utilization looks low because the OS does not know its vCPUs are being descheduled. The instinctive fix, adding even more vCPUs, makes the problem worse.

What this means

For a single-vCPU VM, the scheduler only needs one free pCPU at a time. For an 8-vCPU or 16-vCPU VM, the scheduler must find that many pCPUs with available capacity at the same moment, or close enough to satisfy the relaxed co-scheduling invariant. On a moderately loaded host, this is not always possible. The vCPUs pile up in the READY queue.

Two metrics capture this penalty:

• CPU ready time (%RDY): the percentage of time a vCPU was runnable (had work to do) but was waiting for a pCPU. For an oversized VM, ready time climbs because the scheduler struggles to assemble enough free pCPUs at once.
• CPU co-stop (%CSTP): the time a vCPU in a multi-vCPU VM is halted because the scheduler is waiting for sibling vCPUs to be co-scheduled. The scheduler holds back fast vCPUs so slow ones can catch up, maintaining co-scheduling progress. High co-stop is the definitive signal that a VM has more vCPUs than the scheduler can efficiently handle.

Modern ESXi uses relaxed co-scheduling, which significantly reduces co-stop compared to older strict co-scheduling. If you see sustained co-stop above 1% on a modern host, the oversizing is severe.

flowchart TD
    A[VM perceived as slow] --> B[Admin adds more vCPUs]
    B --> C[Scheduler must find N free pCPUs at once]
    C --> D[%RDY rises: vCPUs wait to run]
    D --> E[%CSTP rises: fast vCPUs held for slow ones]
    E --> F[VM performs worse than before]
    F --> A

The spiral works like this: the admin sees a slow VM, checks guest CPU (looks low), assumes the VM needs more compute, and adds vCPUs. The scheduler now has an even harder co-scheduling problem. Ready time and co-stop rise further. The VM gets slower. The admin adds more vCPUs.

A telling characteristic: the host CPU is not maxed out. It sits at 60-80%, sometimes lower. The host has capacity, but it is fragmented across pCPUs in a way the scheduler cannot reassemble for the oversized VM. Smaller VMs on the same host perform fine because they only need one or two pCPUs at a time.

Common causes

Quick checks

Run these read-only checks on the host running the affected VM. They do not modify any state.

# Launch esxtop and check CPU scheduling metrics
esxtop
# Press 'c' for CPU view, examine per VM world:
#   %RDY   - ready time (vCPU runnable but waiting for pCPU)
#   %CSTP  - co-stop (vCPU held waiting for sibling co-scheduling)
#   %MLMTD - max-limited (throttled by a configured CPU limit)
# Check host pCPU utilization in the PCPU section at the top: %USED
# Press 'm' for memory view, press 'f' to enable NUMA stats fields
# Look at N%L column per VM (local memory access percentage)

# List vCPU counts and CPU usage for all VMs
Get-VM | Select Name, NumCPU, @{N='CpuUsageMhz';E={$_.ExtensionData.Summary.QuickStats.OverallCpuUsage}} | Sort-Object NumCPU -Descending

# Check per-VM ready time (realtime, last 6 samples of 20s each)
Get-Stat -Entity (Get-VM "myvm") -Stat cpu.ready.summation -Realtime -MaxSamples 6
# Convert to percentage: value_ms / (20000 * vCPU_count) * 100 = %RDY

How to diagnose it

1. Confirm the host is not simply out of CPU. Check host %USED in esxtop. If the host is above 90%, you have genuine overcommitment, not oversizing. The oversizing pattern shows up when the host is at 60-80% and specific VMs still have high ready time.

2. Identify which VMs have high %RDY. In esxtop CPU view, sort by %RDY. Look for wide VMs (4 or more vCPUs) with sustained ready time above 5%. Note whether smaller VMs on the same host have low ready time. If they do, the host has capacity but cannot schedule the wide VMs efficiently.

3. Check %CSTP on the affected VMs. Co-stop above 1% sustained is worth investigating. Above 3% sustained is a strong indicator of oversizing. On modern ESXi with relaxed co-scheduling, any sustained co-stop means the problem is real, not noise.

4. Check in-guest CPU utilization. This is the critical data point. If a 16-vCPU VM is using 20% of its guest CPU, it only needs roughly 3-4 vCPUs of actual compute. The remaining vCPUs exist only to make the scheduler’s job harder. Use in-guest monitoring (top, Task Manager, /proc/stat) or the vCenter-reported guest CPU usage.

5. Rule out CPU limits. Check %MLMTD in esxtop. A limit-constrained VM may show low %RDY but high %MLMTD. If %MLMTD is non-zero, the fix is removing the limit, not changing vCPU count. Limits are often inherited from templates or resource pools and are invisible to the guest.

6. Check NUMA alignment. Compare the VM’s vCPU count to the host’s cores per NUMA node. A VM with 16 vCPUs on a host with 10 cores per socket spans two NUMA nodes by definition. Check N%L in esxtop memory view. Locality below 80% means memory accesses are crossing the interconnect, adding latency to every memory operation.

7. Consider whether snapshots are contributing. High co-stop values can be caused or worsened by deep snapshot chains. If the affected VM has long-standing snapshots, consolidate them during a maintenance window and re-check co-stop.

Metrics and signals to monitor

Fixes

Right-size the VM

The primary fix. Reduce the vCPU count to match actual workload demand. A 16-vCPU VM using 20% guest CPU needs approximately 3-4 vCPUs. After the reduction, the scheduler has a smaller co-scheduling problem and ready time should drop.

Reducing vCPU count requires a VM power cycle. Schedule a maintenance window. After the change, monitor %RDY and %CSTP for several hours under normal load to confirm improvement.

If the application has periodic spikes that justify a wider configuration, consider whether CPU shares would be a better tool than raw vCPU count. Shares let the VM claim more pCPU time during contention without the co-scheduling penalty of carrying unused vCPUs.

Fix NUMA alignment

If the VM’s vCPU count exceeds the host’s cores per NUMA node, it spans nodes by definition. Two options:

• Reduce vCPU count below the cores-per-NUMA-node threshold so the VM fits within a single NUMA node.
• Accept the spanning penalty knowingly. If the workload genuinely needs the vCPUs, verify that the vNUMA topology presented to the guest matches the physical NUMA layout. On vSphere 6.5 and later, changing cores-per-socket does not change vNUMA presentation. ESXi auto-selects the optimal vNUMA topology.

Also check whether CPU Hot Add is enabled. On vSphere versions before 8.0, enabling CPU Hot Add disables vNUMA entirely, which degrades wide VMs that depend on NUMA locality. On vSphere 8.0 with hardware version 20 or later, Hot Add preserves vNUMA. If you are on an older version and running a wide VM, disable Hot Add unless you genuinely need it.

Remove forgotten CPU limits

If %MLMTD is non-zero, find and remove the CPU limit. Check the VM’s resource allocation, any parent resource pool, and the template the VM was cloned from. The default for “unlimited” is -1 in the API, not 0. A limit-constrained VM looks identical to CPU contention from inside the guest but is actually artificial throttling.

Consolidate snapshots

If co-stop is elevated and the VM has old or deep snapshots, consolidating them can reduce or eliminate the co-stop penalty. Plan for a maintenance window because consolidation stuns the VM briefly and is I/O intensive.

Prevention

• Right-size against in-guest utilization, not peak provisioning assumptions. A VM that never uses more than 4 vCPUs of actual compute should not carry 16.
• Monitor %CSTP alongside %RDY for every multi-vCPU VM. Co-stop is the early warning signal for oversizing, and many teams that already monitor ready time miss it entirely.
• Audit VM templates for vCPU count. Templates with 8 or 16 vCPUs propagate the oversizing problem to every cloned VM. Set template defaults to a moderate count and increase per-VM only when justified by utilization data.
• Gate vCPU increases on ready-time data. Before adding vCPUs to a slow VM, check %RDY. If ready time is already elevated, adding vCPUs will make it worse. If ready time is near zero and the guest is genuinely CPU-bound, more vCPUs may help.
• Keep wide VMs NUMA-aware. Match vCPU count to the smallest host in the cluster’s cores-per-NUMA-node, or accept the spanning penalty deliberately.

How Netdata helps

• Per-second granularity on %RDY and %CSTP catches scheduling spikes that disappear in vCenter’s 5-minute rolled-up averages. A VM that hits 40% ready for 30 seconds every few minutes shows as approximately 5% in a 5-minute average but is visibly degraded at per-second resolution.
• Correlating host CPU utilization with per-VM ready and co-stop in a single view distinguishes genuine overcommitment (host at 90%, all VMs have high ready) from oversizing (host at 65%, specific wide VMs have high ready while small VMs do not).
• ML anomaly detection on scheduling metrics surfaces gradual co-stop creep as a VM’s workload shifts over time, even before it crosses a static threshold.
• Tracking in-guest CPU utilization alongside hypervisor-level ready time makes the right-sizing decision data-driven. If guest CPU is low and ready time is high, the VM is oversized, not underpowered.
• Alerting on %MLMTD alongside %RDY prevents the common blind spot where a CPU-limited VM looks healthy on ready time alone.

Related guides

• vSphere CPU ready time high (%RDY): VMs starved while the guest looks idle
• How vSphere actually works in production: a mental model for operators
• vSphere monitoring checklist: the signals every host, VM, and vCenter needs
• vSphere monitoring maturity model: from survival to expert