The vmstat command is a powerful, cross-platform utility for monitoring system performance on Linux and Unix systems. It provides a real-time snapshot of key metrics including CPU utilization, memory usage, swap activity, and I/O operations—all in a single, concise output. Unlike top, which focuses on per-process resource consumption, vmstat gives you a holistic view of system-wide behavior, making it indispensable for diagnosing bottlenecks at the infrastructure level.

Basic usage involves two parameters: the interval (in seconds) between samples and the number of samples to collect. For example:

root@ubuntu:~# vmstat 2 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  0      0 3498472 315836 3819540    0    0     0     1    2    0  0  0 100  0

This command captures one sample after a 2-second delay. To continuously monitor, omit the count:

root@ubuntu:~# vmstat 2
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  0      0 3499840 315836 3819660    0    0     0     1    2    0  0  0 100  0
 0  0      0 3499584 315836 3819660    0    0     0     0   88  158  0  0 100  0
 0  0      0 3499708 315836 3819660    0    0     0     2   86  162  0  0 100  0
 0  0      0 3499708 315836 3819660    0    0     0    10   81  151  0  0 100  0
 1  0      0 3499732 315836 3819660    0    0     0     2   83  154  0  0 100  0

Here, data is sampled every 2 seconds until manually stopped. Now, let’s break down each field and its implications.

• r: Number of processes waiting for CPU time. If this consistently exceeds the number of CPU cores, the system is CPU-bound. A sustained value above 5–10 indicates severe contention.
• b: Processes in uninterruptible sleep, typically blocked on I/O. A high value suggests storage or network latency issues.
• swpd: Virtual memory (swap) in use. Non-zero values idnicate physical memory pressure. Persistent usage may require memory upgrades or workload redistribution.
• free: Available physical memory. This reflects unused RAM not allocated to buffers or caches.
• buff: Memory used for block device buffers—metadata like directory structures and file permissions. Typically stable unless large file operations occur.
• cache: Memory used to cache file contents. Linux intelligently repurposes idle RAM here to accelerate disk access. High cache usage is normal and beneficial.
• si: Kilobytes per second read from swap into RAM. Sustained values above zero suggest memory exhaustion. Investigate memory-hungry processes.
• so: Kilobytes per second written from RAM to swap. Like si, persistent values indicate memory pressure.
• bi: Blocks received from block devices (e.g., disks) per second. Each block is 1024 bytes. High values indicate heavy read activity. For example, bulk data transfers may push this beyond 140,000 blocks/sec (~140 MB/s).
• bo: Blocks sent to block devices per second. High values reflect heavy write activity. Consistently high bi and bo together suggest I/O saturation.
• in: Interrupts per second, including timer and hardware interrupts. Elevated values may point to high device activity or misconfigured hardware.
• cs: Context switches per second. Frequent switches (e.g., >10,000/sec) indicate excessive process/thread scheduling, often due to high concurrency. In web servers like Nginx or Apache, tuning worker counts to minimize context switches improves throughput.
• us: Percentage of CPU time spent executing user-space code. High values (e.g., >80%) suggest application-level CPU load, such as encryption, compression, or complex computations.
• sy: Percentage of CPU time spent in kernel mode—system calls, I/O, and scheduling. High sy often correlates with heavy disk or network I/O.
• id: Percentage of CPU time idle. Ideally, us + sy + id + wa sums to 100%. Low id combined with high us or sy signals full CPU utilization.
• wa: Percentage of CPU time waiting for I/O completion. A rising wa value (e.g., >20%) indicates storage latency or saturation. This is often the root cause of poor application responsiveness despite low CPU usage.

When diagnosing performance issues, correlate these metrics: high wa with high bi/bo points to disk bottlenecks; high cs with low id suggests thread overload; and sustained si/so signals memory constraints. Use vmstat alongside tools like iostat and pidstat for comprehensive analysis.