vmstat

What it does

vmstat prints a compact, single-line-per-interval summary combining process queue counts, memory usage (free, buffers, cache, swap), paging/swapping activity, block I/O, and CPU time breakdown. It's designed to be scanned at a glance to spot the overall health of a system in one view — is the CPU saturated, is the system swapping, is disk I/O high — before diving into more specialized tools like mpstat or iostat for detail on any one dimension.

Beginner examples

• vmstat — print a single since-boot-average report
• vmstat 1 — print a fresh report every 1 second, continuously
• vmstat 2 5 — print 5 reports at 2-second intervals, then stop
• vmstat -s — print a longer table of memory/event counters, then exit

vmstat 1 5

Advanced examples

• Watch for swapping under memory pressure: vmstat 1 and check the si/so (swap in/out) columns — nonzero values mean the system is actively swapping.
• Check run queue length relative to CPU count to gauge CPU contention: vmstat 1 | awk '{print $1}'
• Get memory sizes in a friendlier unit: vmstat -a -S M 1
• Inspect disk-level statistics separate from the standard report: vmstat -d 1
• Add timestamps to each line for later correlation with logs: vmstat -t 1 10

vmstat -a -S M 1 5

Common mistakes

• Reading the very first output line as "current" state — it's actually an average since boot and can be misleading; the interesting data starts from the second line onward.
• Ignoring si/so (swap in/out) columns and missing that a "slow" system is actually thrashing swap rather than being CPU-bound.
• Confusing the b (blocked) column with a bug or hang, when it just reflects normal processes waiting on disk or network I/O.
• Treating free memory as the true measure of available memory — Linux uses spare RAM for buffers/cache, so low "free" with high "buff"/"cache" is normal and healthy, not a memory shortage.

Tips

• Watch the r column against your CPU core count: if r consistently exceeds the number of cores, processes are queued waiting for CPU time.
• Nonzero si/so values are a strong, immediate signal of memory pressure — worth checking before assuming a slowdown is CPU or disk related.
• Use vmstat -s for a one-off diagnostic dump of cumulative counters (like total page faults and context switches) rather than the streaming interval report.
• Combine vmstat 1 in one pane with mpstat -P ALL 1 and iostat -x 1 in others during a live incident — together they cover CPU, memory, and disk from three angles.

Best practices

• Always look at more than the first line of output; discard the boot-average row when diagnosing current behavior.
• In monitoring scripts, bound the run with a count (vmstat 1 60) rather than letting it run indefinitely and needing to be killed manually.
• Interpret vmstat alongside free -h for memory and iostat -x for disk — vmstat is a great triage starting point but its columns are terse and benefit from cross-checking.
• Note the CPU time columns (us, sy, id, wa, st) sum to 100; a nonzero st (steal time) on a VM means the hypervisor is withholding CPU cycles from your instance.

Real-world use cases

• First-response triage during a "server feels slow" incident: one glance at vmstat 1 shows whether it's a CPU, memory, or I/O problem before digging deeper with other tools.
• Detecting swap thrashing on a memory-constrained server by watching for sustained nonzero si/so values.
• Capacity planning: logging vmstat samples during a load test to see if the run queue (r) grows faster than available cores as traffic increases.

Common interview questions

• What do the r and b columns in vmstat mean? r is the number of processes ready to run and waiting for CPU; b is processes blocked, usually on I/O. Comparing r to your core count reveals CPU contention.
• How do you tell if a Linux system is swapping heavily? Watch the si (swap in) and so (swap out) columns in vmstat 1; sustained nonzero values indicate active, ongoing swap activity rather than just allocated swap space.
• Why does the first line of vmstat's output look different from later lines? It's a cumulative average since boot, not a real-time sample; every line after that reflects just the most recent interval.