The Paradox: Laggy Virtual Machines Despite Abundant Resources
Have you ever found yourself scratching your head: users are complaining about slow application response times, yet vCenter shows CPU usage at only 15-20%? Even worse, the more vCPUs you add, the slower the virtual machine seems to get.
I once handled an 8-host ESXi cluster running SQL Server for a production team. This VM was allocated 16 vCPUs on a 24-core physical CPU. Although resources appeared plentiful, query execution times suddenly jumped from 200ms to 5 seconds. After a closer look, I identified the culprit: CPU Ready Time (%RDY). This is a metric that VMware system administrators must know by heart to avoid unnecessary headaches.
What is CPU Ready Time?
Simply put, CPU Ready Time is the duration a virtual machine is ready to process a task but must wait in line because no physical CPU (pCPU) is available.
Imagine an ESXi host is a restaurant with 8 tables. A group of 4 guests (a VM with 4 vCPUs) walks in. According to the VMware scheduling mechanism, the restaurant must have 4 tables vacant at the same time to serve this group. If only 3 tables are free, the group of 4 must wait outside. That waiting time is Ready Time.
When you over-allocate vCPUs (Oversubscription), you make things difficult for the CPU Scheduler. The more vCPUs a VM has, the harder it is to find enough simultaneous free physical cores. As a result, Ready Time spikes, causing lag even when the total system load remains low.
How to Diagnose CPU Ready Time using esxtop
While vCenter provides performance charts, I always rely on esxtop. This tool provides real-time data accurate to the millisecond.
Step 1: Log in to the ESXi Host
Enable SSH on the host, then use PuTTY or a Terminal to log in.
Step 2: Run the Diagnostic Command
esxtopPress the ‘c’ key to ensure you are on the CPU monitoring screen.
Step 3: Interpreting the %RDY Metric
Look at the %RDY column. This is the most critical health indicator for a VM:
- Under 5%: System is extremely stable.
- 5% – 10%: Signs of contention are appearing. You will notice slight latency during operations.
- Over 10%: Alarm state. Applications will timeout or freeze frequently.
Quick tip: If you are viewing metrics in vCenter (measured in ms), use this formula to convert it to a percentage (based on the default 20,000ms update interval):
(%RDY) = (CPU Ready Value / 20000) * 100Practical Experience to Eliminate CPU Ready Time
Here are 4 tactics I often use to get a system back to a “smooth green” state.
1. The “Right-sizing” Rule: Less is Often More
Many people have a habit of over-provisioning vCPUs just to be safe. In reality, most Web or App servers only need 2 vCPUs.
If you see high %RDY, don’t hesitate to reduce the number of vCPUs. I once downsized a VM from 8 vCPUs to 4 vCPUs, and the results were surprising: processing speed doubled. The reason was that the VM no longer had to wait as long to acquire 8 physical cores simultaneously.
2. Remove CPU Limits
Many admins accidentally set a CPU Limit. When a VM hits this threshold, ESXi forces it to wait, causing an artificial spike in %RDY. Always keep the Limit set to Unlimited. If you want to prioritize resources, use Shares instead of Limits.
3. Set Power Management to High Performance
By default, Dell or HP servers often have power-saving modes enabled in the BIOS. This slows down the process of “waking up” CPU cores.
You should switch Power Management in both the BIOS and the ESXi configuration to High Performance. Doing this on ESXi is quick: Go to Host -> Configure -> Hardware -> Power Management -> Edit.
4. Quickly Scan the System with PowerCLI
If you manage hundreds of VMs, you can’t check each one manually. Use this script to filter out VMs that have been “starving” for CPU over the last 5 minutes:
$vms = Get-VM
foreach ($vm in $vms) {
$stat = Get-Stat -Entity $vm -Stat cpu.ready.summation -Realtime -MaxSamples 1
$readyPercent = ($stat.Value / 20000) * 100
if ($readyPercent -gt 5) {
# Warning: VM [Name] has %RDY = [Value]%
Write-Host "Warning: VM $($vm.Name) has %RDY = $($readyPercent)%" -ForegroundColor Red
}
}Conclusion
CPU Ready Time is like a silent killer in a virtualized system. To avoid this issue, never allocate more vCPUs than the number of physical cores on a single socket (to avoid NUMA node conflicts).
Start with a minimum configuration and only increase it when CPU usage actually hits the 80% threshold. Regularly monitoring the %RDY metric will save you hours of useless troubleshooting. If your VM is still laggy, open up esxtop right away!
