Which tool answers which question?
| Tool | Answers | Package | Cost |
|---|---|---|---|
| top / htop | Which process is using the CPU or memory right now; load and CPU steal (st) | procps (top), htop | Free, built in or one package |
| vmstat | Is the box swapping (si, so), is the run queue longer than the cores (r), how much I/O wait | procps | Free, built in |
| iostat -x | Which disk is saturated: %util, await and queue size per device | sysstat | Free |
| pidstat -d / -u / -r | Which process is doing the I/O, the CPU or the page faults, per second | sysstat | Free |
| sar | What CPU, memory, disk and network looked like at 3 a.m. yesterday | sysstat, with its collector enabled | Free |
| atop | Per-process history, so you can replay which process was busy during a past slowdown | atop | Free |
| dmesg / journalctl | OOM kills, disk I/O errors, services restarting in a loop | Built in | Free |
| perf | Where the CPU time goes inside a process, down to the function | linux-tools (matches your kernel) | Free |
| bpftrace and BCC tools | Latency the counters hide: runqlat (CPU queueing), biolatency (disk), opensnoop, execsnoop, tcpretrans | bpftrace, bpfcc-tools; kernel 4.x or newer | Free |
| Netdata | Per-second charts of hundreds of metrics on each server | Netdata agent | Free open-source agent; paid cloud plans |
| Opservo | Why the server is slow, in a sentence, with what changed and the fix; history for every server | One-command agent | Free for 2 servers; Growth ₹999 (about $12) per server per month |
Compared on 10 November 2026
In what order should you use them?
Work from the resource down, not from the tool up. For each resource ask how busy it is, whether work is queueing for it, and whether it is reporting errors. The first resource that is saturated is usually the answer.
uptime; nproc # load vs cores
vmstat 1 5 # r > cores? si/so non-zero? wa high?
free -m; df -h; df -i # memory, space, inodes
iostat -x 1 3 # %util and await per disk
pidstat -d 1 5 # which process does the I/O
top -o %CPU # which process burns CPU
dmesg -T | tail -50 # OOM kills, I/O errors
journalctl -p err --since -1h # what failed in the last hourIf all of that is healthy and the app is still slow, the time is inside the app or the database: profile with perf, measure queueing with runqlat and biolatency, and read the database’s slow-query log.
What if the slowdown already passed?
Every tool above except sar and atop shows only now. When the complaint is "the site was slow at 3 a.m.", you need data that was recorded at 3 a.m.: enable sysstat’s collector or run atop as a service, or use a monitor that keeps history and puts it next to what changed (deploys, restarts, config edits) in the same window.
Where does a monitor fit next to these tools?
The command-line tools are precise but need someone at the terminal who knows which one to run. A monitor runs the same checks on every server all the time. Opservo’s agent collects system, process, disk, kernel-log, service and database facts every 60 seconds; its rules name the cause ("MySQL is waiting on disk: one query pattern is doing full scans of orders") and the change that came before it, and each finding carries the command to fix it, which you can run from the dashboard with approval.
curl -sSL https://api.getopservo.com/install.sh | sudo bashLast updated 2026-11-10.