CPU troubleshooting starts by separating load, utilization, and responsiveness. No single number establishes a bottleneck, so compare several time windows and relate host metrics to the workload users actually experience.
Process Utilization · Lesson 4
CPU Monitoring
Learn how to interpret Linux load averages alongside CPU count, utilization, and task state.
Reading uptime
uptime provides a compact starting point:
$ uptime
17:23:35 up 1 day, 5:59, 2 users, load average: 0.00, 0.02, 0.05
The final three values are load averages over approximately 1, 5, and 15 minutes. Comparing them shows direction: a much larger 1-minute value can indicate rising load, while a larger 15-minute value can indicate load that is falling.
In what order does uptime display load-average windows?
Understanding Linux Load
Linux load average counts tasks that are runnable, including those using or waiting for CPU, plus tasks in uninterruptible sleep, commonly associated with I/O. It is therefore not the same as CPU utilization.
A load of 4.0 has different implications on systems with one and sixteen logical CPUs. Find the number of processing units available to the system with:
$ nproc
CPU quotas, affinity, virtualization, and container limits can reduce capacity visible to a particular workload, so host CPU count is only a starting point.
Why is load average not a CPU-utilization percentage?
Comparing Load with CPU Activity
Collect multiple samples rather than relying on one output. Useful companions include:
$ top
$ vmstat 1
$ mpstat -P ALL 1
top combines host and process views. vmstat shows runnable and blocked task counts with CPU categories. mpstat, supplied by sysstat on many distributions, shows per-CPU activity. Availability and exact fields vary, so use local manuals.
High load with busy CPUs can indicate CPU demand. High load with notable blocked tasks, I/O latency, or I/O-wait observations points toward another constrained resource. Low average utilization can also hide one saturated CPU or a brief latency spike.
What is the best next step after observing a high load average?
Evaluating Capacity and Impact
There is no universal rule that load must always remain below CPU count. Batch systems may accept queues, while interactive services may violate latency targets before that point. Establish a baseline for the same host and workload, then compare response time, throughput, error rate, saturation, and resource use.
What should determine whether observed load is acceptable?
Lesson complete
You finished CPU Monitoring
You can now interpret load average as one part of a CPU investigation.
Read the 1-, 5-, and 15-minute load windows.
Distinguish task load from CPU-time percentages.
Compare load with available processing capacity.
Correlate repeated host measurements with service outcomes.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account