AFF A30/A50 “high CPU” in ONTAP
A high processor number is evidence, not a verdict. Correlate it with client latency, workload activity, and time-aligned counters before declaring an AFF controller saturated.
Short answer
A public NetApp Community discussion reports an AFF A30 showing one logical thread of each physical core busy even with little foreground I/O. A NetApp employee attributed that case to the platform’s simultaneous multithreading view and ONTAP background work. That explanation is useful context, but it is case-specific community guidance—not a published guarantee for every A30, A50, ONTAP release, or workload.
What the numbers mean
| Signal | What it can tell you | What it cannot prove |
|---|---|---|
sysstat CPU | A broad node-shell utilization view during the sample. | Which workload caused it, or that clients are slow. |
| Per-processor busy | How work is distributed across logical processors. | A fixed physical-core topology across every AFF model. |
| QoS workload CPU | CPU attributed to workloads on a selected node. | All internal/background consumption. |
| Workload latency | ONTAP latency and subsystem components for QoS workloads. | Host, fabric, application, or end-to-end latency by itself. |
If alternating processor IDs look busy, record the pattern; do not label odd IDs “system cores” or even IDs “data cores.” ONTAP documentation describes processor busy as time executing non-idle processes. Physical/logical topology and scheduling behavior are platform- and release-sensitive.
10-minute, read-only triage runbook
Run these during the reported slowdown and again during a known-good period. Replace node names; stop continuous displays with Ctrl+C.
1. Establish node health and foreground demand
cluster::> system health status show
cluster::> qos statistics workload performance show -node node1 -iterations 10 -rows 10
cluster::> qos statistics workload resource cpu show -node node1 -iterations 10 -rows 10The performance view reports IOPS, throughput, and latency by workload. The resource view attributes CPU to QoS workloads. Look for a stable top consumer and whether latency rises with its CPU share; sample output varies, so do not paste illustrative values into an alert rule.
2. Break down latency
cluster::> qos statistics workload latency show -node node1 -iterations 10 -rows 10Compare the total with the Network, Cluster, Data, Disk, QoS, NVRAM, Cloud, and other columns exposed by your release. A large component narrows the next investigation; zero in a component during one interval does not certify that subsystem.
3. Inspect the broad node view
cluster::> set -privilege advanced
cluster::*> system node run -node node1 sysstat -x 1
cluster::*> set -privilege adminsysstat is node-shell triage. Options and columns can vary; use system node run -node node1 sysstat -h and the support guidance for your ONTAP version. Preserve several minutes that include the symptom instead of relying on one peak line.
4. Check whether efficiency work aligns with the window
cluster::> volume efficiency show -vserver * -fields state,status,progress
cluster::> volume show -vserver * -fields node,aggregate,percent-used
cluster::> event log show -time >1h -severity ERRORThese commands expose efficiency status, placement/capacity, and recent errors; they do not prove causation. Do not disable efficiency, deduplication, compression, or Snapshot-related activity merely to make a CPU graph look quieter. Any change should follow an impact assessment and the support matrix for that release.
Decision matrix
| Observed together | Interpretation | Action |
|---|---|---|
| High CPU; normal client and ONTAP latency; demand is served | No demonstrated incident. | Baseline it and tune alerting to service impact. |
| High CPU; one workload leads CPU/IOPS; its latency rises | Possible workload contention. | Check placement and QoS; capture before changing policy. |
| High CPU; latency dominated by Network or Cluster | CPU may be coincidental. | Follow the implicated network/LIF/cluster path. |
| High CPU; low foreground work; repeating processor pattern | Could match background work or logical-thread reporting. | Compare a healthy peer and open a support case if behavior is new or impact exists. |
| Node errors, panic/reboot, takeover, or severe sustained latency | Real availability/performance risk. | Preserve evidence and escalate immediately. |
What to capture before escalation
- Cluster and node names, exact ONTAP release, controller model, and incident time with time zone.
- Client-observed latency/error evidence and the affected SVMs, volumes, LUNs, or shares.
- Outputs from the same window for workload performance, workload CPU, and workload latency.
- A short
sysstatcapture showing the repeating pattern, plus a known-good comparison. - AutoSupport case data requested by NetApp Support. Use
system node autosupport invoke -node * -type all -message "case-number incident-time"only when it matches your organization’s support procedure.
For a deeper collection, use the package and invocation supplied by NetApp Support; see the perfstat capture runbook.
Facts, inferences, and limits
There is no universal “bad CPU percentage” in this guide. Your latency objective, workload mix, failover headroom, and support guidance determine the operational threshold.