Linux Commands & Shell Skills
top vs htop vs btop: Process Monitors Compared
Every live server question starts with a process monitor, and the trio of top, htop, and btop is a readability-versus-ubiquity trade. top sits on every Unix box including rescue images and is honest in a boring way; htop adds interactive sorting, tree views, and color that make triage faster; btop delivers the full dashboard with per-process detail at the price of install footprint and a roomy terminal. The interface is the smallest part: CPU, memory, load, and disk-wait tell most of the story in any of the three.
Key points
- top is the universal fallback and a fine tool: P sorts by CPU, M by memory, 1 explodes per-core, and W writes your layout to ~/.toprc so the next session inherits it.
- htop is the everyday instrument: F6 sorts, F4 filters by string, F5 gives the process tree, and the color bars read at a glance from across a dark room at 3 a.m.
- btop is the dashboard: sharper detail (per-core graphs, I/O stats, network rates) but it wants terminal space, a working TERM, and a distro that built it; on a cramped rescue console top still wins.
- Read load average correctly: Linux folds uninterruptible disk-wait into the number, so load 20 on 4 cores may be storage queue, not CPU; the %wa line in top settles that argument before iostat even opens.
- Memory totals lie to nobody who knows the vocabulary: 'buff/cache' is reclaimable and 'available' is the honest figure; a 95-percent-used bar with 4GB available is a filesystem doing its job, not an emergency.
- Kill thoughtfully: htop's F9 offers signal choice in the tree, top's k takes a PID, and both reward asking which parent spawned the runaway before you kill twenty identical children instead.
- Record what you see: top -b -n 1 > /tmp/top.state at the moment of the incident is the evidence that survives closing the terminal; a ticket without it is a mystery, a ticket with it usually closes itself.
- The swap and disk-wait lines outvalue the CPU bar: swap in/out rates, D-state counts, and iowait describe behavior under pressure; a pristine CPU percent flatters exactly when things hurt.
Field note
Reading 90 percent 'used' memory as an emergency once cost us an hour hunting a leak that was page cache living large. The 'available' column and the D-state rows told the truth in five minutes once we knew where to look.
Frequently asked questions
Is a high load average automatically bad?
No: the number includes runnable and uninterruptible tasks. Compare it to core count, check %wa in top, and follow with iostat or btop's I/O graphs before deciding between CPU sizing and storage fixes.
Should I panic about 'used' memory near 100 percent?
No: Linux fills memory with page cache on principle; 'available' is the real number, and 'used' high plus 'available' low is the combination that actually warrants action.
Which monitor should a junior learn first?
htop for daily speed, top for the day the rescue console is the only tool present; both skills transfer, and the sort/filter muscle memory is the part that actually saves time.
Why do memory figures disagree between tools and columns?
Definitions differ: RSS double-counts shared libraries, PSS apportions them, and buffers/cache slide between categories; compare like with like and quote the column name when you cite a number.
How Kinetikatech helps with linux commands & shell skills
We've handled this hundreds of times: The commands and scripting habits that decide whether an administrator operates a server or fights it: search, transform, transfer, and supervise text and processes with the tools that live in every base install. With Linux Server Security and Server Management, you get the full loop, we assess, we implement, we watch it around the clock, and we pick up within 30 minutes when it matters.