13.3 Interpreting Workload Performance: CPU Contention, CPU Ready, Memory, and I/O Latency
Key Takeaways
- Objective 4.4 names four specific signals to recognize from Prism analytics: CPU contention, CPU ready, memory constraints, and I/O latency.
- CPU ready time measures how long a vCPU was ready to run but waiting for a physical core, which is the definitive indicator of CPU oversubscription.
- High CPU ready is often worsened by oversized VMs, because a wide VM must wait for enough cores to be simultaneously free.
- High latency during periods of low IOPS points away from the VM own demand and toward contention, a rebuild, or a slow device.
- Because AHV VMs are fixed-size by default, memory pressure frequently shows up as paging inside the guest rather than as a hypervisor-level alert.
13.3 Interpreting Workload Performance: CPU Contention, CPU Ready, Memory, and I/O Latency
Objective 4.4 is the only objective in the blueprint that lists specific metrics by name: "based on Prism analytics/metrics, recognize potential oversubscription or contention issues, such as CPU contention, CPU ready, memory constraints, I/O latency."
It is an interpretation objective. You are not asked to fix the problem — you are asked to look at a chart and say what it indicates.
CPU Contention and CPU Ready
These two are related and constantly confused, so separate them clearly.
The difference
CPU usage tells you how busy the CPU is. CPU ready tells you how long virtual machines waited to get CPU.
CPU ready time measures the time a virtual CPU was ready to run but could not be scheduled, because no physical core was available. The guest operating system is not idle and not busy — it is queued.
This is why CPU ready is the more diagnostic of the two. A host at 70% CPU usage with high CPU ready is oversubscribed in a way that raw usage does not reveal.
Reading it
CPU ready is normally expressed as a percentage of time per vCPU. As broad guidance:
| CPU ready (per vCPU) | Interpretation |
|---|---|
| Low single digits | Normal; scheduling contention is negligible |
| Around 5% | Worth investigating; the workload is waiting noticeably |
| Above ~10% | Significant contention; users will perceive it |
Treat these as orientation rather than as thresholds published by Nutanix. What matters is the trend and its correlation with user-visible slowness — which is exactly what an entity chart (section 13.1) is for. The blueprint references "CPU Ready Time" and "Interpreting CPU Ready values" for this reason.
The counter-intuitive part: bigger VMs can be slower
A hypervisor scheduling a VM with many vCPUs generally needs enough physical cores available at once to run it. On a busy host, a 16-vCPU VM waits for a 16-core opening while a 4-vCPU VM slips into a much more frequently available 4-core gap.
The consequence is genuinely counter-intuitive and a favourite exam framing: an oversized VM can perform worse than a right-sized one on the same host. When CPU ready is high on a wide VM, the remedy is often to reduce its vCPU count, not increase it.
CPU overcommit ratios
Section 6.1 covered the practical ratios: roughly 1:1 to 2:1 vCPU-to-physical-core for latency-sensitive workloads, up to about 4:1 for general enterprise workloads. Push far beyond that and CPU ready climbs.
Memory Constraints
Memory behaves differently from CPU on AHV, and the reason traces directly back to section 6.1: AHV VMs are fixed-size by default.
Because fixed-size memory is reserved rather than shared, memory pressure appears in two distinct places:
At the cluster level, the constraint is placement. If no host has enough unreserved physical memory to satisfy a VM's allocation, that VM cannot power on there. Symptoms: power-on failures, VMs unable to migrate to a particular host, or a node that cannot be evacuated for maintenance because there is nowhere for its VMs to go.
Inside the guest, the constraint is paging. A guest given too little memory pages to its own swap file. The hypervisor sees a healthy VM; the application sees terrible performance; and the symptom appears as disk I/O, not as a memory alert. This is the single most misdiagnosed performance pattern in virtualization.
[!TIP] If a guest shows sustained high disk I/O to its system or swap volume with no application explanation, suspect memory starvation inside the guest before suspecting storage. Where memory overcommit has been enabled on a VM (AOS 6.1 and later), the balloon driver introduces a second mechanism to consider — reclaimed memory the guest thought it had.
I/O Latency
Latency is how long an I/O takes to complete, and it is the metric users actually feel. Throughput and IOPS describe volume; latency describes experience.
Reading latency in context
A latency number alone means little. Latency alongside IOPS means a great deal:
| Pattern | Likely interpretation |
|---|---|
| High latency, high IOPS | The workload is demanding a lot; may simply be at capacity, or need more resources |
| High latency, LOW IOPS | Something other than this workload is responsible — contention from a neighbour, a rebuild in progress, or a failing device |
| Latency rising over weeks at flat IOPS | Growing contention or degrading hardware |
| Latency spikes aligned with a maintenance event | A rebuild or upgrade, and probably expected |
The second row is the one worth memorizing. The blueprint reference list includes "High latency spikes during times of low IOPS on a cluster" precisely because that combination is diagnostic: if a VM is barely asking for I/O and still waiting, the cause lies outside that VM.
Where in the stack
Prism reports latency at more than one point — at the VM, at the controller, at the disk. Comparing them localizes the problem: latency high at the disk but not the controller suggests a device, while latency appearing at the VM but not below it suggests something in the guest or in its queueing.
Bringing the Four Together
| Observation | Points to |
|---|---|
| CPU ready high, especially on wide VMs | CPU oversubscription; consider right-sizing vCPU counts |
| CPU usage high, CPU ready low | The workload is genuinely busy — not a contention problem |
| VM cannot power on or migrate to a host | Memory placement constraint (fixed-size reservations) |
| Guest paging heavily to its own swap | Memory starvation inside the guest |
| High latency with high IOPS | Demand at or beyond capacity |
| High latency with low IOPS | External contention, rebuild, or failing device |
[!IMPORTANT] Method matters more than any single number. Use a metric chart to find the outlier, then an entity chart on that object to correlate CPU ready, latency, IOPS, and memory on one timeline, with alerts and events overlaid so maintenance activity is visible. That is Objective 4.1 and Objective 4.4 working together, which is how the blueprint intends them to be used.
A virtual machine with 16 vCPUs performs worse than a similar 4-vCPU virtual machine on the same busy host, and its CPU ready time is high. What is the most likely explanation?
Prism shows a virtual machine with high storage latency during a period when its IOPS are low. What does this pattern most likely indicate?
A guest operating system shows sustained heavy disk I/O to its own swap volume, while the hypervisor reports the virtual machine as healthy. What should be suspected first?