Linux High CPU Usage Troubleshooting

Evidence first: a high load average is not the same as high CPU utilization. Linux load includes runnable tasks and tasks in uninterruptible wait, commonly I/O wait.

Fast troubleshooting flow

Confirm the user-visible slowdown↓Check CPU count + load trend↓Check CPU states in top↓Find the hottest process/thread↓Decide: user CPU, kernel CPU, I/O wait or VM steal?↓Fix the workload/root cause↓Verify under representative load

1 — Establish CPU capacity and load context

nproc
uptime

8
19:22:11 up 14 days,  load average: 12.41, 10.88, 7.32

The three load values are roughly 1, 5 and 15 minute averages. Compare them with CPU count only as context: load can include runnable work and uninterruptible waits. A rising 1-minute value above the 5/15-minute values suggests the pressure is getting worse, but it still does not identify the resource.

2 — Check what the CPUs are doing

top

%Cpu(s): 91.2 us,  4.8 sy,  0.0 ni,  2.1 id,  1.3 wa,  0.0 hi,  0.6 si,  0.0 st

High us points toward application CPU work; high sy means more time in the kernel; high wa means CPUs were idle while outstanding I/O existed; st can matter on virtual machines when the hypervisor is servicing other vCPUs. Do not call an I/O-bound host a CPU problem just because load is high.

3 — Identify the hottest processes

ps -eo pid,ppid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -15

  PID  PPID USER     %CPU %MEM     ELAPSED CMD
18421 18390 app      389.4  8.1       18:42 python3 worker.py
 2210     1 postgres  42.7  6.4    02:14:03 postgres: writer

A process can exceed 100% CPU on a multi-core system because it can use multiple logical CPUs. Confirm the command, owner and elapsed time before acting.

4 — If one process is hot, inspect its threads

top -H -p <PID>

    PID USER      PR  NI    VIRT    RES S  %CPU  %MEM     TIME+ COMMAND
  18439 app       20   0    4.2g   1.8g R  99.3  11.6  18:21.44 worker-7
  18440 app       20   0    4.2g   1.8g S   2.1  11.6   0:42.18 worker-8

What to check: whether one thread repeatedly dominates CPU or several threads share the load. This is useful for multi-threaded runtimes where one thread spins while the overall process is large. Record the thread ID and correlate it with application/runtime diagnostics when available.

5 — Distinguish CPU work from resource pressure

cat /proc/pressure/cpu
cat /proc/pressure/io

some avg10=22.18 avg60=14.70 avg300=6.12 total=...
full avg10=0.00 avg60=0.00 avg300=0.00 total=...

some avg10=0.41 avg60=0.28 avg300=0.19 total=...
full avg10=0.05 avg60=0.03 avg300=0.01 total=...

What to check: whether CPU stall time is elevated during the incident and whether I/O pressure is actually the stronger signal. The example supports CPU contention more than I/O contention. Next: correlate with top/ps and the workload before deciding to tune or scale it.

On kernels with Pressure Stall Information (PSI), some shows the percentage of time at least some tasks were stalled on that resource over recent windows. Use it as supporting evidence, not a universal threshold. If /proc/pressure is absent, continue with the other checks.

6 — Choose the remediation from the evidence

One application is CPU-bound — inspect its workload, concurrency, loops, serialization/compression, query behavior or recent code/config changes.

Many legitimate workers saturate CPUs — reduce concurrency/load or add capacity if the workload is expected.

I/O wait dominates — continue with Disk I/O Troubleshooting.

Memory pressure accompanies the slowdown — continue with High Memory / OOM.

Do not immediately kill or renice the top process. First identify what it owns and whether stopping it is service-impacting. A busy database, backup or batch worker may be doing necessary work.

Verify

Reproduce or observe representative load. Confirm latency/throughput recovered, CPU states are healthy for the workload, the offending process no longer grows unexpectedly, and load trends return toward the host’s normal baseline.