vmstat, short for virtual memory statistics, is a Linux command-line tool that prints a compact, interval-based summary of system activity: runnable and blocked processes, memory, swapping, block I/O, interrupts, context switches and CPU time. In Linux monitoring, it is the classic first instrument for deciding whether a slow system is limited by CPU, memory or storage.
vmstat belongs to the procps package and reads its data from kernel interfaces such as /proc/stat, /proc/meminfo and /proc/vmstat. It needs no daemon and no configuration, which makes it available on almost every Linux server, including minimal installations and rescue environments.
How vmstat samples system activity
vmstat is usually run with a delay and a count, as in vmstat 2 10, which prints ten lines two seconds apart. Each line after the first shows rates and averages for that interval, calculated from the difference between two snapshots of kernel counters.
The first line is special: it reports averages since boot for rate columns, so it often looks calm even on a busy machine. Experienced administrators ignore it and read the following lines, which reflect the current load.
Gauge values such as free memory are instantaneous readings, while rates such as interrupts per second are averaged over the interval. Short intervals of one or two seconds reveal bursts, whereas intervals of thirty or sixty seconds are better for trend logging with less noise.
Reading the vmstat columns
The default output groups columns under six headings: procs, memory, swap, io, system and cpu. The table explains each column and the values that deserve attention.
| Column | Meaning | Warning sign |
|---|---|---|
| r | Runnable tasks, running or waiting for CPU | Consistently above CPU count |
| b | Tasks in uninterruptible sleep, usually I/O | Persistently above zero |
| swpd | Swap space in use, KiB | Growing steadily |
| free, buff, cache | Idle memory, buffers and page cache, KiB | Low free alone is normal |
| si, so | Memory swapped in and out per second | Sustained nonzero so |
| bi, bo | Blocks read and written per second | High together with high wa |
| in, cs | Interrupts and context switches per second | Sudden large increase |
| us, sy, id, wa, st | CPU time percentages | High wa or high st |
The CPU columns add up to about 100 percent of all CPUs combined. us is user code, sy is kernel code, id is idle, wa is time idle while waiting for I/O, and st is time stolen by the hypervisor for other virtual machines. A low free value is not a problem by itself, because Linux deliberately uses spare memory for cache.
Useful vmstat options
Beyond the default view, vmstat offers several report modes that answer more specific questions. The following table lists the most useful options.
| Option | Report | Typical use |
|---|---|---|
| -a | Active and inactive memory instead of buffers and cache | Assessing memory reclaim |
| -S M | Units in mebibytes | Readable output on large hosts |
| -w | Wide output | Avoids merged columns |
| -t | Timestamp on each line | Logging and correlation |
| -s | Table of memory and event counters | One-time snapshot |
| -d | Per-disk read and write statistics | Quick disk check |
| -m | Kernel slab cache usage | Investigating kernel memory |
A practical command for incident work is vmstat -w -t -S M 1, which prints wide, timestamped lines in mebibytes every second until interrupted. Redirecting it to a file creates a simple record that can be compared with application logs.
vmstat compared with other monitoring tools
vmstat is a system-wide summary tool, so it complements rather than replaces the other Terms in Linux monitoring. The comparison shows when each tool is the better choice.
| Tool | Focus | Best for |
|---|---|---|
| vmstat | System-wide rates in one line | First triage and logging |
| top and htop | Per-process CPU and memory | Finding the busiest process |
| iostat | Per-device I/O latency and utilization | Diagnosing storage bottlenecks |
| Pressure stall information | Time tasks stall on CPU, memory or I/O | Measuring real contention |
| strace and lsof | One process’s system calls and files | Deep investigation of one program |
A typical workflow starts with vmstat to classify the bottleneck, then moves to iostat for storage, to top or htop for CPU consumers, or to pressure stall information for an exact measure of how much work is delayed.
Interpreting patterns and avoiding mistakes
vmstat is most valuable when its columns are read together rather than one at a time. The patterns below are the ones administrators recognize most quickly.
- High r with low id indicates CPU saturation; more runnable tasks than cores means work is queuing.
- High b and high wa point to slow storage or a saturated device, which iostat can confirm.
- Sustained si and so mean active swapping, a sign of memory shortage that hurts latency severely.
- High st on a virtual machine shows that the host is overcommitted, not that the guest is misconfigured.
- High cs with modest load can reveal lock contention or too many threads competing for cores.
A frequent mistake is treating wa as a measure of disk speed. It only counts idle CPU time while I/O is outstanding, so a fully busy CPU can hide an I/O problem, and a mostly idle machine can show high wa with little real impact.
In plain words
vmstat is like the dashboard of a car for a Linux computer. Every second or two it prints one line showing how hard the engine works, how full the tank is and whether anything is waiting in traffic.
By watching a few of those lines, an administrator can tell which part of the machine is struggling. It might be the processor, the memory or the disks. That tells them where to look next, before they spend time on the wrong problem.
A real-world example
An online shop reports that its order system becomes slow every afternoon. The operations engineer connects to the 8-core application server during the slowdown and runs vmstat -w -t 2.
The output shows r between 3 and 5, id above 40 percent and wa near 2 percent, so the CPU is not saturated. However, free memory is very low, si and so show hundreds of kilobytes swapped per second, and swpd keeps growing.
The engineer concludes that the server is short of memory, not processor power. A memory leak in a reporting worker is identified with per-process tools, fixed and redeployed. The next afternoon, vmstat shows swap activity at zero and response times return to normal.