When a host feels slow, SSH lags, or a deploy “just hangs,” you need a live view of who is burning CPU, who is holding RAM, and whether the load average actually matches the hardware. One-shot ps snapshots go stale while you stare at them. That is what top, htop, and btop are for — real-time process monitors that refresh as the machine changes.

On nearly every Linux box you can start with top (procps). Prefer htop when you want clearer bars, search, and a tree of parent/child processes. Prefer btop when you want a fuller dashboard (CPU, memory, disks, network) in one screen. The sections below lead with top, then show how htop and btop make the same triage faster.

Warm-up: read the top header

Your playground is the live machine in front of you. Launch the classic monitor:

top

Press q to quit when you are done looking. The header (above the process list) is where load and resource pressure show up first. A batch snapshot prints the same idea without taking over the terminal:

top -b -n 1 | head -n 12

Typical header shape (numbers will differ on your host):

top - 00:50:00 up  2:13,  0 user,  load average: 4.54, 4.31, 4.12
Tasks: 434 total,   2 running, 431 sleeping,   0 stopped,   1 zombie
%Cpu(s): 38.3 us, 10.6 sy,  0.0 ni, 48.9 id,  2.1 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  11889.1 total,    496.2 free,   7828.1 used,   5105.9 buff/cache
MiB Swap:  20080.5 total,  20080.5 free,      0.0 used.   4061.0 avail Mem

Read it with intent:

  • load average — 1-, 5-, and 15-minute averages of runnable (and uninterruptible) work
  • %Cpu(s) — especially id (idle) and wa (I/O wait)
  • MiB Mem / Swap — used vs available; growing swap with low idle often means memory pressure
  • Tasks — how many processes; a climbing zombie count deserves a glance

Note: Interactive top is for watching. top -b -n 1 is for scripts, tickets, and pasting a snapshot into chat without leaving a full-screen UI open on a shared session.

Load average troubleshooting

Load average is not “percent CPU.” It is a queue-length style metric: roughly how much work is ready to run (or stuck in uninterruptible sleep, often disk). Compare it to how many CPUs you have.

Count logical CPUs:

nproc

Rule of thumb for a first pass:

  • Load well below nproc with high id → the box is mostly idle; slowness may be elsewhere (network, locks, a single-threaded app)
  • Load around or above nproc with low id → CPU saturation; find the hot processes next
  • Load high while id is still healthy but wa is elevated → often I/O wait; CPU is not the only story

Also glance at the three load numbers together. A spike only on the 1-minute average that the 15-minute still shows as low is a short burst. All three elevated means sustained pressure.

Note: On a 4-core machine, load 4 is “about fully busy.” The same load 4 on a 64-core server is light. Always pair uptime or the top header with nproc before sounding the alarm.

Find CPU and RAM hogs in top

Below the header, top lists processes. By default the list is ordered so the hottest CPU users float up. Watch %CPU, %MEM, and RES (resident RAM).

While top is running, these keys matter most:

  • P — sort by CPU (the usual first move)
  • M — sort by memory
  • 1 — toggle per-CPU lines instead of a single aggregate %Cpu(s)
  • k — kill a PID (you will be prompted; be sure before confirming)
  • q — quit

For a non-interactive “top CPU offenders” paste:

top -b -n 1 -o %CPU | head -n 20

Memory-oriented snapshot:

top -b -n 1 -o %MEM | head -n 20

Sample process rows:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   6797 alice     20   0 1397.0g 741540 123664 S  41.7   6.1  29:46.65 java
   9556 alice     20   0 1448.1g 432188 151948 S  25.0   3.5   9:00.91 chrome

Note: VIRT is rarely the number you chase; RES (and %MEM) better reflect RAM actually held. Kill from top only when you already know the process is safe to stop — prefer a graceful service restart when you can.

htop is optional but common. If it is missing:

# Debian/Ubuntu
sudo apt install htop

# Fedora/RHEL
sudo dnf install htop

Launch it:

htop

You get color meters for CPU cores and memory, a scrollable process list, and fewer cryptic key chords for everyday work. Useful keys:

  • F6 (or >) — choose a sort column (CPU%, MEM%, …)
  • F3 (or /) — search by process name
  • F5 — tree view (parent/child), handy for “what spawned this worker?”
  • F9 — kill menu with signal choice
  • F2 — setup (meters, columns)
  • q — quit

Per-core bars make it obvious when one CPU is pegged while others are idle — a classic single-thread bottleneck that a single aggregate %Cpu line can hide.

Note: Reach for htop on interactive SSH sessions when you are hunting a named service or want tree context. Keep using top -b when you need a scriptable snapshot on a minimal host that only has procps.

btop: one-screen resource dashboard

btop (and related tools in the same family) adds panels for disks and network alongside CPU, memory, and processes. Install when you want that overview (package names vary slightly by distro):

# Debian/Ubuntu (if packaged)
sudo apt install btop

# Fedora
sudo dnf install btop

Launch:

btop

Use the process list the same way you would in htop: identify the hot PID, confirm memory, then decide whether to dig into logs or restart a unit. The extra graphs help when the question is “is this CPU, disk, or network?” before you open three other tools.

Navigation is mostly keyboard-driven (arrows / vim-style keys depending on version; h or the help overlay shows the map; q quits). Exact binds can differ by release — treat the on-screen help as authoritative.

Note: Prefer btop on a workstation or bastion where you want situational awareness. Prefer top/htop on locked-down servers where you cannot install extra packages and only need process triage.

A quick incident workflow

When someone says “the server is slow,” run the same short path every time:

  1. Check load vs cores: uptime and nproc (or read the top header).
  2. Open top or htop; sort by CPU (P / F6 → CPU%).
  3. Check whether the hot process also owns large RES / %MEM; if memory is tight and swap is climbing, sort by memory next.
  4. Note %wa — high I/O wait with modest user CPU points at disk or NFS, not only a hot loop.
  5. Act with intent: restart the known service, kill only a runaway you own, or jump to logs (journalctl -u …) once you have the unit/PID.

Batch form for a ticket comment:

nproc
uptime
top -b -n 1 -o %CPU | head -n 15

Note: The monitor tells you who is expensive. It does not explain why — pair it with service logs and recent deploys once the PID or unit name is clear.

Quick reference card

Keep this nearby until the keys become muscle memory:

GoalCommand / key
Interactive toptop
Batch snapshottop -b -n 1
Sort CPU (top)P
Sort memory (top)M
Per-CPU lines (top)1
Top by CPU (batch)top -b -n 1 -o %CPU | head
CPU countnproc
Load onlyuptime
htophtop
htop searchF3 or /
htop treeF5
htop sortF6
btopbtop
Quit UIsq

Practice drills

Use your own machine. Install htop or btop only if you want those drills; the top steps work everywhere procps is present.

  1. Print a one-shot top header and process list (batch mode), then note your 1-minute load and nproc.
  2. In interactive top, sort by memory, then by CPU, then quit.
  3. Show the five highest %CPU processes in a paste-friendly batch command.
  4. Open htop (if installed), search for ssh or another known process, and toggle tree view.
  5. Write a three-line triage snippet: CPU count, uptime/load, and top CPU offenders.

When you are ready to compare, here are solid answers — not the only ones, but clear and portable:

top -b -n 1 | head -n 20
nproc
# in top: press M, then P, then q
top -b -n 1 -o %CPU | head -n 12
htop   # then F3, type a name; F5 for tree; q to quit
nproc; uptime; top -b -n 1 -o %CPU | head -n 15

If you can work through those five comfortably, you already cover most real process-monitor work: reading load against core count, spotting CPU and RAM hogs, taking ticket-ready snapshots, and moving to htop/btop when the richer UI speeds up the same decisions. Start with top, escalate to htop or btop when the host allows it, and always interpret load in light of nproc.