Linux high CPU usage: find the culprit and take back your machine

What this covers

High CPU usage on Linux shows up as a hot laptop, loud fans, and a desktop that stutters on every click. This guide walks you from a quick snapshot to a live view, helps you decide whether a process or a systemd service is responsible, and then shows how to deprioritize or tune the system so the machine becomes responsive again — without blindly killing processes.

Symptom

Take a quick snapshot of what's eating CPU

Before digging deeper, get a one-shot list of every process with its CPU share. Sort the output by the %CPU column to spot the obvious offender instantly. If one process sits at or near 100%, you already know where to focus; if many processes share the load, you'll need the live view in the next step.

$ ps aux

Watch the load live and identify the culprit

A static snapshot can miss intermittent spikes. Open the interactive viewer to watch per-core CPU meters in real time, sort by CPU, and confirm whether the heavy process is persistent or bursty. Note the PID of the offender — you'll need it for the fix steps. You can also kill a runaway process directly from here if it's clearly misbehaving.

$ htop

Check whether a systemd service is to blame

If the heavy process belongs to a service (databases, containers, background daemons), per-cgroup view groups usage by service name instead of raw PID, which makes it obvious which service is responsible. This is the fastest way to answer 'is it something the system itself is running?'

$ systemd-cgtop --order=cpu --depth=2

Profile the suspect process over time

For an intermittent or misbehaving process, capture time-series CPU, memory, and I/O statistics for its PID over a few minutes. This tells you whether the load is steady CPU work, memory pressure causing swap thrash, or I/O wait — each points to a different fix.

$ pidstat -u -r -d -p 1234 2 5

Lower the priority of the heavy process

If the CPU hog is a job you can't stop (a backup, a compile, a batch import), don't kill it — deprioritize it instead. Raise its nice value using the PID you noted earlier so it yields CPU time to your interactive programs. The desktop should stop lagging immediately while the job keeps running in the background.

$ sudo renice -n 10 -p 12345

$ sudo renice -n 0 -p 12345

Prevent recurrence: launch heavy jobs at low priority

If this happens repeatedly with the same script or command, start it at a lower priority from the beginning so it never competes with your interactive work. This is the preventive version of the previous step.

$ nice -n 10 ./backup-script.sh

Make sure the CPU isn't stuck in a slow governor

Sometimes the problem isn't one process but everything feeling sluggish while usage is high: cores stuck in a powersave governor take longer to finish the same work, so utilization stays pegged. Switch to the performance governor to let cores ramp up and clear the queue faster. This changes system-wide power behavior, so revert it afterwards if it was set intentionally.

$ sudo cpupower frequency-set -g performance

$ sudo cpupower frequency-set -g powersave

How to confirm it worked

Reopen the live process view after applying a fix: overall CPU usage should have dropped or, if the heavy job is still running, your interactive apps should respond smoothly while it runs in the background at lower priority.

Undo everything

Every command above can be reverted. Run these in order to undo all of it.

$ sudo cpupower frequency-set -g powersave
sudo renice -n 0 -p 12345

Review before running — some steps may not be independent.

Sources

• Ubuntu Manpage: ps - report a snapshot of the current processes
  manpages.ubuntu.com · technical · 2026-09-17
  Evidence: "ps displays information about a selection of the active processes"; the u option selects the user-oriented format with USER, %CPU, %MEM, and COMMAND headers.
• ps - report a snapshot of the current processes
  man7.org · technical · 2026-09-17
  Evidence: The ps page documents the a, u, and x options ("u Display user-oriented format" including USER, %CPU, %MEM, and COMMAND columns) and describes ps as reporting "a snapshot of the current processes".
• htop(1) — interactive process viewer
  man7.org · technical · 2026-09-17
  Evidence: The htop man page describes it as an interactive text-mode process viewer that allows scrolling vertically and horizontally, unlike top.
• htop - an interactive process viewer
  htop.dev · vendor-doc · 2026-09-17
  Evidence: The official htop site describes real-time CPU, memory, and swap meters plus interactive process sorting and killing.
• systemd-cgtop(1) — Debian bookworm
  Debian Manpages · community · 2026-09-17
  Evidence: Same synopsis systemd-cgtop [OPTIONS...]; describes ordering by CPU, memory or I/O load and the --depth= cut-off.
• systemd-cgtop(1) - Linux manual page
  man7.org · community · 2026-09-17
  Evidence: Documents systemd-cgtop [OPTIONS...] with options --order=, --depth=, -P, -m showing task/CPU/memory/I/O usage per control group.
• pidstat(1) - Report statistics for Linux tasks
  Ubuntu Manpages · technical · 2026-09-17
  Evidence: pidstat reports statistics for Linux tasks (processes): -u CPU usage, -r memory, -d I/O, -p selects a task, with interval and count arguments.
• renice(1) — Ubuntu manpage
  Ubuntu · community · 2026-09-17
  Evidence: Ubuntu manpage shows renice alters the scheduling priority of running processes, with -p targeting process IDs

Last verified: 2026-09-21

Related guides