Study guide
13.3 Interpreting Workload Performance: CPU Contention, CPU Ready, Memory, and I/O Latency
Nutanix Certified Associate NCA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Nutanix Cloud Platform & HCI Foundations
1.1 Nutanix NCA Exam Overview, Format, and Objectives 1.2 Hyperconverged Infrastructure (HCI) vs. Traditional 3-Tier Architecture 1.3 The Nutanix Enterprise Cloud Portfolio (NCI, NUS, NCM, EUC, NC2)
2 Chapter 2: Platform Architecture & Distributed Core Services
2.1 Hardware Building Blocks: Nodes, Blocks, Clusters, and Quorum 2.2 Controller VM (CVM) Architecture, Datapath, and Autopathing 2.3 Core Distributed Services: Cassandra, Stargate, Curator, Zookeeper, and Genesis
3 Chapter 3: Prism Administration & Cluster Operations
3.1 Prism Element vs. Prism Central Architecture and Interface Navigation 3.2 Entity Management, Categories, and Role-Based Access Control 3.3 Nutanix Licensing Tiers, Add-ons, and Pulse Telemetry
4 Chapter 4: AOS Distributed Storage Fabric & Data Placement
4.1 Storage Pools, Storage Containers, and vDisk Virtual Architecture 4.2 Redundancy Factor (RF2 vs. RF3), Failure Domains, and Fault Tolerance 4.3 Data Locality Mechanics and Intelligent Lifecycle Management (ILM)
5 Chapter 5: Storage Optimization & Business Continuity
5.1 Storage Efficiency: Compression, Deduplication, and Erasure Coding (EC-X) 5.2 Space-Efficient Redirect-on-Write (ROW) Snapshots and Zero-Byte Clones 5.3 Protection Domains, Consistency Groups, and Disaster Recovery Replication
6 Chapter 6: AHV Virtual Machine Lifecycle Management
6.1 AHV VM Provisioning, Resource Allocation (vCPU, vRAM, Disks), and Boot Types 6.2 Nutanix Image Service and Virtual Machine Templates 6.3 Nutanix Guest Tools (NGT) Architecture, Features, and Deployment 6.4 AHV High Availability (HA), Acropolis Dynamic Scheduling (ADS), and Affinity Rules
7 Chapter 7: AHV Networking & Flow Security Fundamentals
7.1 AHV Virtual Networking Architecture, Open vSwitch (OVS), and Bridges 7.2 Host Network Uplinks, Virtual Switch Configuration, and NIC Bonding Modes 7.3 Virtual Networks: Managed vs. Unmanaged Networks and IPAM 7.4 Nutanix Flow Network Security & Microsegmentation Fundamentals
8 Chapter 8: Cluster Maintenance, Health Monitoring & Support
8.1 Nutanix Cluster Health Monitoring, Alerts, and Events Engine 8.2 Nutanix Cluster Check (NCC) Architecture and Execution 8.3 Life Cycle Manager (LCM) and Rolling Non-Disruptive Upgrades 8.4 Nutanix Support Ecosystem: Diagnostics, Log Gathering, and Support Bundles
9 Chapter 9: Recognizing Nutanix Solutions, Hypervisors & the Product Portfolio
9.1 Supported Hypervisors for NCI and Feature Supportability 9.2 NCI Core Components, Configurations, and Common Deployment Scenarios 9.3 Nutanix Unified Storage: Files, Objects, and Volumes Use Cases 9.4 Nutanix Database Service (NDB) and Database Automation 9.5 Nutanix Kubernetes Platform, Enterprise AI, and End-User Computing
10 Chapter 10: Nutanix Tools — Migration, Deployment, and Validation
10.1 Nutanix Move: Cross-Hypervisor and Cloud Migration 10.2 Foundation and Foundation Central: Imaging and Cluster Deployment 10.3 X-Ray, Collector, and the Objective 1.3 Tool Inventory
11 Chapter 11: Cluster Configuration, Security & Hardware Maintenance
11.1 Cluster Services Configuration: DNS, NTP, SMTP, and SNMP 11.2 Cluster Security Options: Lockdown, Encryption, and the Recycle Bin 11.3 Node Maintenance Mode, Host Shutdown, and Cluster Shutdown 11.4 Cluster Expansion: Node Types and In-Node Expansion Capabilities 11.5 Out-of-Band Management and Remote Console Access
12 Chapter 12: Storage, Network, and Software Administration Tasks
12.1 Volume Groups, vDisk Placement, and Live vDisk Migration 12.2 Network Visualizer, Physical Switch Monitoring, and Network Segmentation 12.3 The Software Compatibility Matrix and Upgrade Path Planning 12.4 Taking and Managing VM Snapshots in Prism 12.5 License Operations: State, Assignment, Reclamation, and Expiry
13 Chapter 13: Performance Analysis, Reporting & Support Operations
13.1 Prism Analysis: Metric Charts, Entity Charts, and Custom Reports 13.2 Custom Alert Policies and Behavioural Anomaly Detection 13.3 Interpreting Workload Performance: CPU Contention, CPU Ready, Memory, and I/O Latency 13.4 Creating Support Cases, Required Documentation, and Insights
13.3 Interpreting Workload Performance: CPU Contention, CPU Ready, Memory, and I/O Latency
Key Takeaways Explain This Topic AI
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.
Last updated: September 2026
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.