For a live CPU view, use top or htop. For per-CPU stats, use mpstat -P ALL. For load average over time, use uptime or cat /proc/loadavg. Load average is the most-misunderstood number in Linux performance. A load of 1.0 on a single-core system means the CPU is 100% busy. A load of 4.0 on a 4-core system means the same thing. The team that knows how to read load has the right picture.
Table of contents
- The top command: live CPU view
- The htop command: same data, nicer interface
- The mpstat command: per-CPU stats
- Reading load average
- Finding which process is using the CPU
- What load average does NOT tell you
- FAQ
The top command: live CPU view
The right tool for a live view of CPU usage is top. The default output has the CPU summary at the top, the process list below, and updates every 3 seconds. The CPU summary line:
top - 15:23:42 up 30 days, 2 users, load average: 0.45, 0.38, 0.42
Tasks: 234 total, 1 running, 233 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.2 us, 1.4 sy, 0.0 ni, 95.0 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st
MiB Mem : 15872.1 total, 1432.4 free, 3254.6 used, 11185.1 buff/cache
MiB Swap: 4096.0 total, 0.0 used, 4096.0 free.The CPU fields: us is user-space CPU, sy is kernel-space CPU, ni is nice-time CPU (low-priority processes), id is idle CPU, wa is iowait (CPU waiting for disk), hi is hardware interrupt CPU, si is software interrupt CPU, st is steal time (CPU taken by the hypervisor).
The right answer for “is the CPU busy” is 100 - %idle. If us + sy + ni + wa is high, the CPU is busy with work. If wa is high, the CPU is waiting for disk. If id is high, the CPU is mostly idle.
The right answer for sorting the process list by CPU is to press Shift+P in top. The right answer for sorting by memory is Shift+M.
The htop command: same data, nicer interface
The right tool if you have a nicer terminal is htop. It shows the same data as top but with a colored display, per-core CPU bars at the top, and a tree view by default.
The right installation:
sudo apt install htop # Debian/Ubuntu
sudo dnf install htop # Fedora/RHEL
sudo pacman -S htop # ArchThe right answer is to use htop if you have it. The wrong answer is to install htop from source when the package manager has it.
The mpstat command: per-CPU stats
The right tool for per-CPU stats is mpstat from the sysstat package. The mpstat -P ALL 1 invocation shows stats for every CPU, updated every second:
Linux 6.8.0-31-generic (host) 07/06/2026 _x86_64_ (16 CPU)
03:23:42 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
03:23:43 PM all 3.21 0.00 1.42 0.00 0.00 0.42 0.00 0.00 0.00 94.95
03:23:43 PM 0 3.10 0.00 1.55 0.00 0.00 0.51 0.00 0.00 0.00 94.84
03:23:43 PM 1 2.95 0.00 1.40 0.00 0.00 0.40 0.00 0.00 0.00 95.25
...The right answer for a multi-CPU system is to look at the per-CPU lines, not just the all line. A single process pinned to one CPU will show up as 100% on that CPU and idle on the others. The right answer for a workload that is supposed to use all CPUs is to look at the per-CPU lines and see if they are roughly even.
Reading load average
The load average is the three numbers after load average: in top or uptime. They are the 1-minute, 5-minute, and 15-minute averages of the run queue length. The run queue is the number of processes that are ready to run but waiting for CPU.
The right answer for a single-core system: load of 1.0 means the CPU is 100% busy. Load of 2.0 means there is a queue — two processes are competing for one CPU, and one is waiting. Load of 0.5 means the CPU is half idle.
The right answer for a multi-core system: divide the load by the number of cores. A 4-core system with a load of 4.0 is 100% busy. A load of 8.0 is overloaded — twice as much work as the CPUs can handle.
The right one-liner to get the load average:
uptimeOr read it from /proc/loadavg:
cat /proc/loadavgThe output is 0.45 0.38 0.42 1/234 12345. The first three numbers are the 1/5/15-minute averages. The fourth is the number of running processes and total processes. The fifth is the last assigned PID.
The wrong answer is to alert on load average > 1.0 without considering the number of cores. A 16-core system with a load of 4.0 is at 25% utilization, which is fine. A 1-core system with a load of 4.0 is overloaded.
The right answer for alerting is to alert on load average / nproc. A threshold of 0.7 (i.e., 70% of CPUs busy) is a reasonable starting point for a server. A threshold of 1.0 is overloaded.
Finding which process is using the CPU
The right one-liner to find the top 10 CPU consumers:
ps aux --sort=-%cpu | head -11Or in top, press Shift+P to sort by CPU. The wrong answer is to assume the process at the top of the list is the cause — it might be a CPU-hungry but legitimate process. The right answer is to look at the process and see if it is doing expected work.
For a deep investigation, perf top (from the linux-tools package) shows the kernel and user-space functions that are hot. The right answer is to install perf and use it to find the specific function that is consuming CPU, especially for performance-sensitive workloads.
A common case is that a process is in a tight loop — top shows it at 100% CPU, but the process is not making progress. The right answer is to attach with strace -p <pid> to see what system calls the process is making. The wrong answer is to kill the process — the right answer is to understand what it is doing first.
What load average does NOT tell you
Load average does not include I/O wait, by default. A process waiting for disk I/O contributes to load only if the kernel considers it runnable, which it usually is during I/O wait. The right answer for a process stuck on I/O is to see it in top with wa (iowait) high and the process in D state (uninterruptible sleep).
Load average also does not tell you whether the work is useful. A high load from a busy database is fine. A high load from a runaway script is not. The right answer is to combine load with per-process CPU to understand what the load is doing.
The wrong answer is to use load average as a single number to indicate “is the system OK.” The right answer is to combine load with CPU, memory, disk, and network metrics to get the full picture. Load is one signal among many, not the only signal.
FAQ
What is a good load average?
It depends on the number of cores. The right answer is to keep load / nproc below 0.7 for a typical server. The wrong answer is to alert on a fixed number like 1.0 or 5.0 without considering the cores. A 16-core system with a load of 4.0 is fine; a 1-core system with a load of 4.0 is in trouble.
Why is load high but CPU is idle?
The most common cause is I/O wait. A process is blocked on disk I/O, which counts as runnable for the load average. The right answer is to look at iowait in top or mpstat. The wrong answer is to assume the system is healthy because CPU is idle — high iowait with low CPU is a sign of disk bottleneck.
What is steal time?
Steal time is the percentage of CPU time that the hypervisor took away from your VM to give to another VM. A high steal time means the host is over-committed and your VM is being throttled. The right answer for a high steal time is to either move to a less-loaded host or to ask the cloud provider to reduce the host’s over-commit ratio.
What is iowait?
Iowait is the percentage of CPU time spent waiting for disk I/O to complete. High iowait with low CPU means the disk is the bottleneck, not the CPU. The right answer is to check disk performance with iostat or iotop and see which process is doing the I/O. The wrong answer is to add more CPU — that will not help.
My CPU usage is 100% but nothing seems wrong. Why?
The right answer is to look at what process is using the CPU. A 100% CPU from a busy database, a build process, or a video encoder is normal. The right answer is to check top and identify the process. If the process is doing expected work, the system is healthy. If the process is doing unexpected work (a runaway script, a misbehaving service), the right answer is to investigate further.
What is the difference between load and CPU usage?
Load is the number of processes waiting to run. CPU usage is the percentage of time the CPU is doing work. The two are related but not the same. A system with 100% CPU and 1.0 load (on a single core) is fully busy with no queue. A system with 50% CPU and 2.0 load has a queue — processes are waiting for the CPU. The right answer is to monitor both.
Should I use load average or CPU usage for alerting?
Both. Load average is a leading indicator of trouble (a queue is building). CPU usage is a lagging indicator (the system is fully busy). The right answer is to alert on both: load average / nproc > 0.7 AND CPU usage > 80% sustained for 5 minutes. The right answer for the alert is to fire when both are true.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: