Show CPU usage on Linux with top, htop, mpstat, or sar. The right pick depends on whether you want a live view (top/htop), a per-CPU breakdown (mpstat), or historical data (sar).
Table of contents
- The top command
- The htop command
- The mpstat command
- The sar command
- The /proc/stat approach
- What usually breaks
- The profiling tools
- The CPU affinity
- FAQ
The top command
The right tool for a quick live view:
$ topTop shows the system-wide CPU usage and the top processes. The headers:
%Cpu(s):Total CPU usage, broken down into user, system, idle, iowait, etc.PID, USER, %CPU, %MEM, COMMAND: The top processes by CPU and memory.
Useful keys in top:
P: Sort by CPU.M: Sort by memory.1: Show per-CPU breakdown.k: Kill a process.q: Quit.
The team that uses top daily has the muscle memory to debug CPU issues quickly.
The htop command
The right tool for a friendlier live view:
$ htophtop is top with colors, mouse support, and a cleaner layout. The team that uses htop over top has a better experience but loses the muscle memory for top.
Install with sudo apt install htop (Debian/Ubuntu) or sudo dnf install htop (Fedora/RHEL).
The mpstat command
The right tool for per-CPU stats:
$ mpstat -P ALL 1The -P ALL shows per-CPU stats; the 1 updates every second. The output shows each CPU’s usage, broken down by user, system, iowait, etc.
The team that uses mpstat to find an imbalanced workload (one CPU at 100%, the rest idle) has a thread-pool sizing issue. The fix: more threads, or a different algorithm.
The sar command
The right tool for historical CPU usage:
$ sar -u 1 10The -u shows CPU usage; the 1 10 shows 10 samples at 1-second intervals. The team that runs sar as a daemon collects historical data; sar -u -f /var/log/sa/sa15 reads yesterday’s data.
The team that finds a CPU spike at 3 a.m. in the historical data has the smoking gun for a cron job or scheduled task.
The /proc/stat approach
The right tool for scripting:
$ cat /proc/stat | head -1The first line of /proc/stat has the system-wide CPU usage broken down by category. The team that wants to graph CPU usage in a script reads this twice with a delay and computes the delta.
The team that uses Prometheus node_exporter gets this data automatically, with historical graphs, in Grafana.
What usually breaks
The four pitfalls:
- iowait confuses everyone.
topshows%wa(iowait), which means the CPU is waiting on disk. The team that sees high%wahas a disk problem, not a CPU problem. - Container CPU is shared. In a container, CPU usage is the container’s share of the host. The team that sees 100% CPU in a container has used the container’s allocation, not necessarily the host.
- Multi-core workload imbalance. A single-threaded workload uses one core; the team that sees 100% on one CPU and 5% on others has a single-threaded workload.
- Frequency scaling. Modern CPUs vary their frequency based on load. The team that sees “low CPU but slow performance” has a CPU that’s thermal-throttled or frequency-limited.
The profiling tools
Beyond top and htop, the deeper profiling tools:
perf. The Linux profiler. Records CPU samples, traces kernel events. perf top shows live CPU usage by function. perf record ./myapp records a profile. perf report shows the recorded profile.
strace. Traces system calls. strace -p <pid> shows what a running process is doing (file accesses, network calls). The team that has a “what is this process doing” mystery uses strace.
ltrace. Traces library calls. Similar to strace but for shared libraries.
bpftrace / bcc tools. High-overhead tracing using eBPF. The right tool for deep kernel and application tracing.
FlameGraphs. Visualization of CPU profiles. The team that has a flame graph of a slow function sees exactly where the time is spent.
The team that uses these tools has the deepest possible insight into CPU usage. The team that only uses top has a surface-level view.
The CPU affinity
The right way to control which CPUs a process uses:
taskset. Bind a process to specific CPUs. taskset -c 0,1 ./myapp runs on CPUs 0 and 1 only. The right tool for isolating latency-sensitive workloads.
numactl. Bind a process to specific NUMA nodes. numactl --cpunodebind=0 --membind=0 ./myapp runs on NUMA node 0. The right tool for NUMA-aware tuning.
CPU shares (cgroups). cpu.shares in a cgroup controls relative CPU allocation. The right tool for limiting a process’s CPU usage.
CPU quota (cgroups). cpu.cfs_quota_us and cpu.cfs_period_us control absolute CPU limit. cpu.cfs_quota_us = 50000 and cpu.cfs_period_us = 100000 limits the process to 50% of one CPU.
The team that uses CPU affinity has predictable performance for latency-sensitive workloads. The team that lets the scheduler move processes has unpredictable performance under load.
FAQ
What’s the best tool to show CPU usage on Linux?
top or htop for live. mpstat for per-CPU. sar for historical. /proc/stat for scripting. Prometheus + Grafana for dashboards.
What does ‘iowait’ mean?
The CPU is idle waiting for disk I/O. High iowait = disk problem, not CPU problem. The team that sees high iowait checks disk performance, not CPU usage.
How do I find which process is using CPU?
top sorted by CPU (press P). The team that sees a runaway process kills it with k in top or kill <pid>.
How do I get historical CPU usage?
sar with the sysstat package. The team that runs sar as a daemon collects historical data; the team that doesn’t has no historical view.
What’s the difference between nice and renice?
nice sets the priority when starting a process. renice changes the priority of a running process. Lower nice values = higher priority. The team that uses nice -n -20 ./critical-app runs the app at the highest priority.
How do I find which process is using CPU?
top sorted by CPU (press P). Or ps aux --sort=-%cpu | head. The team that uses ps in scripts has a way to find CPU-heavy processes automatically.
What’s the CPU steal time?
Time the CPU wanted to run but the hypervisor gave it to another VM. On a noisy neighbor VM, steal time is high. The team that sees high steal time has a VM that’s being throttled by the hypervisor; the fix is to move to a less crowded host or get dedicated CPU.
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: