A 60-second first look at a slow Linux server: the command order and what each line answers

Goal

Run a fixed sequence of commands, each answering one question, to get a shortlist of suspect resources before reaching for a heavier tool.

Prerequisites

A shell on the host; the sysstat package for mpstat/pidstat/sar (install non-interactively if missing); enough privilege to read dmesg (with kernel.dmesg_restrict=1, the default on several distributions, it needs root or CAP_SYSLOG).

Steps

1. uptime — load averages and how long the system has run; rising load with an unchanged workload is the first hint something changed.
2. dmesg -T | tail — recent kernel messages with human-readable timestamps (dmesg's manual documents -T/--ctime for exactly this, printing readable time instead of a raw offset). Look for OOM kills, disk errors or NIC resets.
3. vmstat 1 5 — the procs columns (r runnable, b in uninterruptible sleep) and CPU columns together; a large r points at CPU pressure, a large b usually at I/O waits. The first line is an average since boot; read the following ones.
4. mpstat -P ALL 1 5 — per-CPU detail that a system-wide average hides, including %steal on virtual machines.
5. pidstat 1 5 — per-process CPU, so one runaway process does not hide inside a system-wide figure.
6. iostat -xz 1 5 — per-device latency and utilisation, using sysstat's extended (-x) fields; -z hides idle devices, and the first report again covers the time since boot (-y omits it).
7. free -m — memory and swap use in megabytes; judge headroom by the available column, not free, since page cache is reclaimable.
8. sar -n DEV 1 5 — per-interface packet and kilobyte rates, from the same sysstat suite; interface errors and drops are in the separate sar -n EDEV report.
9. sar -n TCP,ETCP 1 5 — connection rates and TCP error counters, including retransmitted segments (retrans/s), without a packet capture.
10. top — a live, sortable summary that confirms what the more specific tools already showed; for a script, run top -b -n 1 (batch mode, one iteration), since interactive top takes over the terminal and never exits by itself.

Expected result

Within about a minute, a shortlist of one or two resources — a specific CPU, a specific device, swapping, or a specific process — worth a deeper tool, instead of an unfocused guess.

Limits and test basis

Every command is read-only; nothing to back up or undo, and the sequence can be repeated freely. A single 5-second sample is noisy; a resource that looks bad only once deserves a longer sample before acting on it. The order follows each tool's own documented purpose, not a fixed diagnostic algorithm.