How to Monitor Server Resource Usage with vmstat

Short introduction (2–3 sentences)

vmstat is a small, widely available tool that reports virtual memory, processes, I/O, CPU, and system activity in a compact tabular format. This tutorial shows you how to interpret vmstat output, gives practical examples for live monitoring and logging, and provides a handy commands table so you can start using vmstat confidently on your servers.

What vmstat is and when to use it

vmstat (virtual memory statistics) is part of the procps/sysstat toolkit on most Unix-like systems. It samples kernel statistics and prints them in a single line per sample, making it excellent for quick diagnosis of memory pressure, excessive swapping, I/O bottlenecks, or CPU saturation without installing heavy monitoring stacks.

Use vmstat when you want:

• Lightweight, immediate insight into memory, swap, I/O, and CPU counters.
• To capture short-term spikes or confirm whether a problem is transient or persistent.
• A command-line tool that’s available on almost every Linux distribution.

Basic usage — view a single snapshot:

$ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 123456  12345 678910    0    0     1     2  100  200  2  1 96  1  0

This prints one snapshot of current counters. For continuous monitoring, pass interval and count (explained later).

Reading vmstat output — fields explained

vmstat’s columns look terse at first but map to useful kernel metrics. Here’s a practical breakdown of the most important fields you’ll see in default output:

• procs: r = runnable (CPU wanting to run), b = blocked (waiting on I/O).
• memory: swpd = swapped memory used, free = free memory, buff = buffers, cache = page cache.
• swap: si = swap-in (kB/s), so = swap-out (kB/s) — non-zero values often indicate memory pressure.
• io: bi = blocks received from block devices (kB/s), bo = blocks sent to block devices (kB/s).
• system: in = interrupts per second, cs = context switches per second.
• cpu: us/user, sy/system, id/idle, wa/iowait, st/steal.

Annotated sample output:

$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 234567  45678 123456    0    0     0     1  200  300  1  1 98  0  0
 2  0      0 200000  45000 120000    0    0     5    20  300  500 10  4 80  6  0

How to interpret:

• If r > number of CPU cores frequently, you have CPU contention.
• High si/so indicates swapping; investigate memory usage and consider adding RAM or tuning applications.
• High bi/bo might indicate heavy disk I/O; correlate with iostat or dstat for per-device detail.
• High wa with low id means CPUs are idle but waiting on I/O — again points to disk or network I/O bottlenecks.

Tip: The first line after headers is averaged since boot and can be misleading. Always inspect subsequent sampled lines when using an interval.

Commands table — common vmstat invocations

This quick reference lists common vmstat command forms and what they’re useful for.

Examples:

# Live sampling every 1 second (press Ctrl+C to stop)
$ vmstat 1

# Collect 10 samples at 5-second intervals and save to file
$ vmstat 5 10 > /var/log/vmstat-$(date +%F-%T).log

# Show event counters in human-readable list (helpful for initial inventory)
$ vmstat -s

Notes:

• Use -n to prevent repeated headers when streaming to files for easier parsing.
• On some systems units differ; check vmstat --help or man page.

Practical monitoring workflows

Here are practical ways to use vmstat in real troubleshooting and routine monitoring.

1. Correlate with other tools:

Combine vmstat with awk to highlight problematic stats (e.g., show samples where swap out > 0):

$ vmstat -n 1 | awk '$7 > 0 { print strftime("%Y-%m-%d %H:%M:%S"), $0 }'
# $7 is 'so' column in default output ordering — adjust if your locale/headers differ.

Capture short-term metrics to a timestamped log for later analysis:

$ vmstat -n 5 288 > /var/log/vmstat-5s-24h.log &
# This captures 24 hours at 5-second intervals (288 samples/hour * 24 hours ≈ 17280, adjust as needed).

Quick live check for CPU vs I/O issues:

$ vmstat 2 6
# Observe 'r' (run queue) and 'wa' (iowait). High r -> CPU bottleneck. High wa -> I/O wait.

• For memory pressure: use top/htop and free -m alongside vmstat to identify processes and exact memory usage.

If vmstat shows high bi/bo or wa, run iostat or dstat to find offending devices:

$ iostat -x 1 5

Practical tip: automated short recordings on suspected times (cron or systemd timer) let you capture intermittent issues that are otherwise hard to reproduce.

Common Pitfalls

Parsing columns without verifying headers: locale differences or repeated headers in logs can shift column numbers; use vmstat -n and verify header positions before scripting.

$ vmstat -n 1 | awk '{print $13}'   # fragile if header positions differ

Ignoring units or platform differences: some implementations use kB, others MB; use flags like -SM or check the man page to avoid confusion.

$ vmstat -SM 1   # show memory in MB on systems that support it

Misreading the first line: the first vmstat sample after starting the command often reflects averages since boot — always rely on subsequent samples when using an interval.

# Wrong: treating first sample as current state
$ vmstat 1 2

Next Steps

• Automate regular collection (cron or systemd timer) and integrate with simple parsers or a centralized logging system (ELK, Grafana) for long-term trend analysis.

Correlate vmstat data with per-device metrics from iostat and process-level info from top to identify root causes.

$ iostat -x 5 5 && top -b -n1 | head -n20

Start capturing short vmstat logs during busy windows: use vmstat -n 5 720 > /var/log/vmstat-5s.log to build a dataset you can analyze.

$ vmstat -n 5 720 > ~/vmstat-5s.log &

This guide covered what vmstat reports, how to interpret its fields, a commands table for quick reference, practical examples for monitoring, and pitfalls to avoid. With the commands and patterns above you can quickly identify whether a server is CPU-bound, memory-starved, or suffering from I/O contention and take the next troubleshooting steps effectively.

👉 Explore more IT books and guides at dargslan.com.