Find What's Using CPU and Memory on Linux (and Stop It)

# top 10 processes by CPU and by memory
ps -eo pid,user,%cpu,%mem,etime,comm --sort=-%cpu | head -11
ps -eo pid,user,%cpu,rss,comm --sort=-rss | head -11
# live view, press P (CPU) or M (memory) to sort
top
# which service or app (cgroup) is responsible
systemd-cgtop
# stop a runaway process: polite first, forced if needed
kill PID
kill -9 PID

Confirm the symptom

uptime
nproc
free -h
vmstat 1 5

Example output:

 14:02:11 up 3 days,  2:41,  2 users,  load average: 7.92, 6.10, 3.05
8
               total        used        free      shared  buff/cache   available
Mem:            15Gi        13Gi       310Mi       1.1Gi       2.4Gi       1.2Gi
Swap:          4.0Gi       3.6Gi       400Mi
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 9  1 3712000 317000  1200 2400000 820  910  1500  2100 4100 9800 38 12 10 40  0

How to read it:

• Load average above nproc for minutes means tasks are queuing. Load counts tasks waiting on disk too, so high load with idle CPU means I/O.
• available in free is what matters, not free. Linux fills spare RAM with cache on purpose.
• us high: a user program. sy high: kernel work (drivers, kworker). wa high: waiting on disk. si/so non-zero continuously: active swapping, so you're out of RAM.

The example above is a memory problem disguised as a CPU problem: swap is nearly full, si/so are high and wa is 40%.

Find the process using CPU

top and htop

top is installed everywhere. htop is friendlier: sudo apt install htop, sudo dnf install htop, sudo pacman -S htop, sudo zypper install htop. Useful keys in top:

• P sort by CPU, M by memory, 1 per-core view.
• c show the full command line (essential for python, java, node).
• H show threads, k kill, r renice.

In top, 100% means one full core, so a process at 400% is using four cores.

Snapshots with ps

ps -eo pid,ppid,user,%cpu,%mem,etime,args --sort=-%cpu | head -15
# full process tree to see what started it
ps -ef --forest | less
pstree -p PID

ps %cpu is averaged over the process lifetime, so a process that just spiked can look small. Use top or pidstat 2 (package sysstat) for the current rate.

Group by service with systemd-cgtop

systemd-cgtop -m        # sort by memory
systemd-cgtop -c        # sort by CPU

This sums usage per service and per app scope (app-gnome-firefox-1234.scope), which catches problems spread over many small processes, like a browser with 40 tab processes. The process management cheat sheet lists more ps, kill and nice options.

Find the memory hog

# RSS is in KiB
ps -eo pid,user,rss,args --sort=-rss | head -10
# shared memory and tmpfs also use RAM
df -h -t tmpfs
# kernel memory (slab), e.g. after heavy file activity
sudo slabtop -o | head -15

RSS counts shared libraries in every process that uses them, so totals add up to more than your RAM. For a precise per-app figure use smem -tk (package smem). If the kernel already killed something, journalctl -k | grep -i "out of memory" shows what, and the OOM killer page explains why. Adding swap or zram buys headroom; see create a swap file.

Usual suspects and their fixes

tracker-miner-fs-3 / localsearch (GNOME)

GNOME's file indexer (renamed from Tracker to LocalSearch in GNOME 47) reads every file in your home directory after a fresh install or after you copy lots of data. Let it finish once. If it keeps going:

# GNOME 47 and later: the CLI is called localsearch
localsearch status
# older GNOME releases
tracker3 status
# if it loops forever: reset its index (it rebuilds once)
tracker3 reset -s

Run localsearch --help to see the reset subcommand on newer releases; the names follow the old tracker3 ones.

Exclude large folders (VMs, code, build directories) under Settings → Search → Search Locations, rather than disabling indexing, which also breaks file search in Files.

baloo_file (KDE Plasma)

balooctl6 status
balooctl6 suspend           # pause for now
balooctl6 config add excludeFolders ~/VMs
balooctl6 disable           # turn off file indexing completely

On Plasma 5 the command is balooctl. You can also configure it in System Settings → Search → File Search.

snapd, packagekitd, gnome-software, dnf makecache

Background updates and metadata refreshes spike CPU and disk for a few minutes. Check with snap changes (Ubuntu) or journalctl -u packagekit -b. On Fedora, dnf-makecache.timer refreshes metadata periodically. These are normally short; if snapd loops, sudo systemctl restart snapd and update it with sudo snap refresh.

kworker, ksoftirqd and kernel threads

High CPU in kernel threads means a driver or interrupt problem. Check interrupts and ACPI events:

watch -n1 "sort -t: -k2 -nr /sys/firmware/acpi/interrupts/gpe* 2>/dev/null | head -5"
watch -n1 'cat /proc/interrupts'
sudo perf top        # package linux-tools-$(uname -r) / perf

One gpeXX counter climbing by thousands per second is an ACPI interrupt storm. A BIOS update often fixes it; a workaround is masking that GPE with echo disable | sudo tee /sys/firmware/acpi/interrupts/gpeXX (lost on reboot; make it permanent with the acpi_mask_gpe=0xXX kernel parameter). Heavy kworker activity alongside high wa usually means disk I/O; check with sudo iotop.

Browsers, Electron apps and GNOME Shell

Firefox (about:processes) and Chrome (Shift+Esc) show which tab is busy. If gnome-shell or plasmashell is high, a broken extension or widget is the usual cause: disable extensions with gnome-extensions disable NAME and re-enable them one by one.

Services stuck in a restart loop

systemctl --failed
journalctl -p warning -b --since "10 min ago"

A service crashing and restarting every few seconds, or a process logging thousands of lines a second (making systemd-journald busy), shows up here. The journalctl cheat sheet helps narrow it down.

Stop, throttle or limit a process

# ask it to exit (SIGTERM), then force (SIGKILL) only if it ignores that
kill PID
kill -9 PID
pkill -f 'pattern in command line'
# lower priority instead of killing (19 = lowest)
renice 19 -p PID
# start something with a hard CPU and memory cap
systemd-run --user --scope -p CPUQuota=50% -p MemoryMax=4G make -j8
# cap an existing service permanently
sudo systemctl set-property name.service CPUQuota=50%

kill -9 gives the program no chance to save data, so try plain kill first. Killing a process that a service manages just makes systemd restart it; stop the service with systemctl stop instead (see the systemctl cheat sheet). For I/O-heavy jobs, ionice -c3 command keeps them from slowing the desktop.

Per-distro notes

• Ubuntu: snapd and the App Center (snap-store) refresh in the background; snap refresh --hold=24h postpones updates if they interrupt work. unattended-upgrades also runs daily.
• Debian: minimal installs have few background jobs, so high usage is almost always an application or driver.
• Linux Mint: Update Manager and the optional Timeshift snapshots can briefly cause heavy disk use.
• Fedora: systemd-oomd kills memory-hungry cgroups under pressure; check oomctl and journalctl -u systemd-oomd. Btrfs maintenance can show as btrfs-transaction threads.
• Arch: after big updates, rebuilding caches (fontconfig, mandb) runs once. AUR builds can saturate all cores; set MAKEFLAGS in /etc/makepkg.conf.
• openSUSE: btrfs-balance and btrfs-scrub timers and Snapper cleanup run periodically: systemctl list-timers | grep -E 'btrfs|snapper'.

Verify the fix

uptime                 # load average falling back below nproc
vmstat 2 5             # si/so near 0, idle (id) high
systemd-cgtop -1

Give load averages a few minutes to settle: the 5- and 15-minute figures lag. If the problem returns after every boot, check what starts it with systemctl list-units --type service --state running and your desktop's autostart folder, ~/.config/autostart/. For broader slowness, start from the general troubleshooting guide.

Frequently asked questions