CPU ready in VMware vSphere: how to read it, which thresholds apply and what the vCPU ratio means

What CPU ready time is in VMware vSphere

CPU ready is the time a virtual CPU was ready to run but could not be scheduled on a physical CPU. vCenter’s Ready counter is a summation in milliseconds over each sample interval, and esxtop on the host shows the same time as %RDY, a percentage of the sample. Converted to a percentage with the formula in Broadcom’s KB 306576 and divided by the number of vCPUs, it can be compared with the thresholds in Broadcom’s KB 438023, which reads “Industry-accepted thresholds are below about 5% per vCPU for benign behavior, 5% to 10% per vCPU for investigate, and above 10% per vCPU for noticeable performance impact.”

Broadcom’s API reference defines the vCenter counter as “Time that the virtual machine was ready, but could not get scheduled to run on the physical CPU during last measurement interval.” In esxtop, the time of each vCPU in a sample divides into run, ready, co-stop and wait, which the documentation writes as 100% = %RUN + %RDY + %CSTP + %WAIT. Time spent ready is time not spent running, so CPU usage does not show it, and the vSphere 8.0 documentation adds that “CPU ready time is dependent on the number of virtual machines on the host and their CPU loads.”

Converting CPU ready from milliseconds to percent

KB 306576 divides the summation value by the chart interval in milliseconds and multiplies by 100, which gives ready % = ms / (seconds × 1000) × 100. Its own example is a Realtime chart value of 1,000 ms, which over the 20-second interval is 5%.

Broadcom KB 306576: default update intervals and the divisor for each chart; last column our arithmetic.

KB 306576 also notes that the result is a sum over the vCPUs and that ready per vCPU can be roughly estimated by dividing by their number. A 4-vCPU VM with 3,200 ms in a 20-second sample is at 16% for the VM. Per vCPU that is about 4%, below KB 438023’s 5%. In a past-day point, the same 3,200 ms is about 1% for the whole VM.

The VM’s own Ready line in the advanced chart is that VM total, and so is the VM’s row in esxtop, since the KB converts one into the other. The per-vCPU lines, which vCenter stores from statistics level 3, and the vCPU worlds in esxtop compare directly with a per-vCPU threshold once in percent. The overview CPU (%) chart shows Ready in percent; the vSphere 8.0 documentation calls it “the average CPU ready time of all virtual CPUs on the virtual machine” but gives no formula and does not say whether it is divided by the vCPU count, so take threshold comparisons from the advanced chart or esxtop.

Longer charts average short contention away. A past-month point covers two hours, so ten minutes at 20% per vCPU with no ready time in the rest of the window read as about 1.7%. vCenter keeps the 5-minute points for one day by default, so judge the thresholds on 20-second data or on those points.

Ready, co-stop and max limited in esxtop and vCenter

esxtop on the host shows the same counters live, as percentages of each sample. In its CPU panel, V displays virtual machines only, each VM’s row covering all of its worlds, so %CSTP and %MLMTD there are VM totals like %RDY. Expanded with e, the row splits into those worlds, whose percentages the documentation gives as “percentage of a single physical CPU”.

vSphere Web Services API reference 8.0 and 9.0 (CPU counters); vSphere 8.0 documentation, esxtop CPU panel (16 September 2026); KB 438023.

Because esxtop counts %MLMTD inside %RDY, a VM held back by a CPU limit shows ready time even when the host has cores to spare, a case for which the vSphere documentation advises raising the limit. The same esxtop page calls %CSTP a statistic “intended for VMware use only”, although KB 438023 and KB 326296 both give a threshold for it.

Broadcom’s API reference puts Ready at statistics level 1, which the vSphere 8.0 documentation names as the default for every collection interval, and Co-stop and Max limited at level 2. With the default level, the history shows ready time but not the counters that explain it.

CPU ready thresholds and where they come from

Broadcom’s documents give thresholds for several counters, listed here as the sources state them.

Broadcom KB 438023 (ESXi 8.0), KB 326296 (ESXi 5.x to 8.x), vSphere 8.0 documentation (16 September 2026), Performance Best Practices for VMware vSphere 9.0 (revision 20250731) and 8.0 Update 1 (revision 20230518).

KB 438023 adds that “Sustained high ready time generally signals CPU contention at the host level rather than undersizing of the individual VM.” More vCPUs for such a VM do not remove the contention that makes it wait.

KB 438023’s figures apply per vCPU and to each counter on its own, while the chart documentation’s 20% applies only with usage above 90%. The same page treats a short spike in ready as a sign that the VM’s resources are in good use, so compare sustained values.

Co-stop, NUMA and VMs with too many vCPUs

Co-stop applies only to VMs with more than one vCPU (KB 438023). Why ESXi holds sibling vCPUs back, and how to right-size a VM from measured peaks, is in our guide to waste in a vSphere estate.

Spare vCPUs cost something even without co-stop, as Broadcom’s best practices guide states: “Configuring a virtual machine with more virtual CPUs (vCPUs) than its workload can use might cause slightly increased resource usage, potentially impacting performance on very heavily loaded systems.”

With NUMA, ESXi keeps each VM’s vCPUs and memory within one physical node when the VM is small enough to fit (KB 438023), and the vSphere resource management documentation says the vCPUs “are constrained to run on the home node to maximize memory locality”. A VM can therefore wait for the cores of its home node while another node has idle cores, until the NUMA scheduler changes its home node, which it can do “to respond to changes in system load”.

A VM with more vCPUs than a node has cores spans nodes (KB 438023), and from nine vCPUs ESXi exposes a vNUMA topology to its guest by default (vSphere 8.0 documentation). For such wide VMs the KB advises splitting the vCPUs evenly across as few nodes as possible and keeping the count at or below the host’s physical cores. In the esxtop memory panel, NHN shows a VM’s current home node, and a separate field shows what share of its memory is local.

The vCPU-to-pCPU ratio and CPU overcommitment

The vCPU-to-pCPU ratio is the number of vCPUs of the powered-on VMs on a host or cluster divided by its physical cores. Broadcom’s Performance Best Practices for vSphere 9.0, like the 8.0 Update 1 edition, says that in most environments ESXi allows full CPU commitment, as many vCPUs as the host has physical cores, “and even significant levels of CPU overcommitment (running more vCPUs on a host than the total number of physical processor cores in that host) without impacting virtual machine performance.” Once a host is CPU saturated, it warns, “performance of some or all of the virtual machines on that host could be significantly reduced”, latency-sensitive workloads in particular.

Count physical cores, not hyper-threads, as that definition does. In esxtop a PCPU is a logical CPU when hyper-threading is active (vSphere 8.0 documentation), so the PCPU count then overstates the cores. VVF and VCF are licensed on physical cores too, every core whether used or not, as our guide to VMware licensing after Broadcom explains.

We found no Broadcom document that sets a general target for the ratio. Ready time depends on how busy the vCPUs are as well as on how many there are, so two hosts at 4 vCPUs per core can show very different ready time, one running lightly used application servers and the other batch jobs that keep every vCPU busy. Use the ratio to plan and ready per vCPU to verify: a host carries the ratio at which ready and co-stop per vCPU stay below KB 438023’s figures in its busiest hour. For hosted capacity, our guide to what dedicated vCPU and RAM mean in an IaaS offer covers the provider’s side.

Finding the cause of high CPU ready time

When ready per vCPU stays above about 5%, check the counters in this order, since each step rules out one cause.

1. Capture the slow period while it happens, in the vCenter Realtime chart at 20-second resolution or in esxtop on the host with V, and express ready per vCPU.
2. Compare %MLMTD with %RDY, and if most of the ready time is max limited, raise or remove the CPU limit that holds the VM back.
3. Check %CSTP, since co-stop above about 3% per vCPU points to too many vCPUs; KB 326296 lowers the count one at a time, with the VM powered off.
4. Check the host’s PCPU usage and esxtop load average, which Broadcom’s best practices read as a warning at 90% and as overloaded at 1 or more; if other VMs on the host also show ready time, move load with DRS or add hosts, as the vSphere documentation suggests.
5. Check NUMA placement in the memory panel, where a wide VM with a low share of local memory, or several large VMs with the same home node, points to sizing against the node.
6. Look at priorities last, since CPU shares and reservations, which the vSphere documentation lists for high-priority VMs, give one VM precedence over the others on the host.

Our infrastructure audit maps clusters and their actual resource usage from the exports you provide. Send us the ready and co-stop figures of the VMs your users call slow, with their vCPU counts.

CPU ready in a host consolidation plan

Consolidation raises the ratio on purpose. Moving the same VMs from six hosts to four of the same size raises the vCPU-to-core ratio by half, as in our worked example of host consolidation under per-core licensing.

CPU ready shows whether the higher ratio slows the VMs down. Record ready and co-stop per vCPU of the largest and busiest VMs over the window that sizes the cluster, at 5-minute resolution, and compare the 95th percentile with KB 438023’s figures. A cluster whose largest VMs already sit between 5% and 10% at month-end has less room to lose cores than its CPU usage suggests. After the move, check the same VMs at the next month-end before the old hosts leave the cluster.

Under VMware optimisation, our engineering partner Vixen.UNO consolidates hosts and clusters in agreed maintenance windows, with a rollback plan at every stage. Write to us with your cluster layout and peak periods through the form below.

What we do

Eurokommerz holds the contract and supplies hardware and licences, with engineering by our partner Vixen.UNO. Under VMware optimisation, the Vixen.UNO team audits the estate, including its actual resource usage, matches editions and subscriptions to your actual workloads and consolidates hosts and clusters; if there is nothing to optimise, we say so. Our infrastructure audit, a separate fixed-price product, works from the documentation and exports you provide, without access to your production systems. The first call is free of charge; the price of the technical assessment is fixed before work begins.

FAQ