vmstat Command in Linux: Monitor CPU, Memory, and Swap in Real Time

Last winter my homelab box was crawling. SSH felt like dial-up, my Jellyfin stream stuttered, and Home Assistant kept timing out. Before reaching for fancy monitoring dashboards, I did what I’ve done a hundred times: I ran vmstat 2 and stared at the columns. Two seconds later I knew the problem wasn’t a runaway process — it was swap thrashing. The vmstat command in Linux is still the fastest way to get a system-level read on what your machine is actually doing, and once you can read its output, you can diagnose 80% of performance problems in under a minute.

This guide walks through every column, every flag I actually use, and the patterns that scream “your server is in trouble.” There’s one column most beginners completely misinterpret — we’ll get to that in a moment.

What Is vmstat and Why Every Sysadmin Needs It

The name vmstat stands for virtual memory statistics, but that name undersells it. In one short row of numbers, you get CPU breakdown, memory state, swap activity, block I/O, and process queue depth. No GUI, no agent, no installation on most systems. It’s been part of the procps-ng package for decades and ships with Ubuntu, Debian, RHEL, Fedora, Arch — basically every distribution you’ll touch.

Get a VPS from as low as $11/year! WOW!

I treat vmstat as my dashboard warning light. It doesn’t tell me which process is misbehaving, but it tells me which category the problem lives in: CPU, memory, or disk. From there I jump to a more specific tool. Brendan Gregg, Netflix’s Senior Performance Architect, lists vmstat as one of the first commands to run in his famous Netflix Linux Performance Analysis in 60,000 Milliseconds methodology. There’s a reason: it’s fast, it’s universal, and it’s never wrong.

“vmstat, iostat, and the other procps tools are the fastest way to get a system-level view of what a machine is doing. They’ve been around for decades for a reason — they work, they’re fast, and they require no installation.” — Brendan Gregg, Netflix

One detail trips up almost every newcomer: the first line of output is a historical average since the last boot, not real-time data. We’ll come back to that — it matters more than people realize.

Installing vmstat

Before you even try to install it, run this:

vmstat --version

Nine times out of ten you’ll get a version string back and you’re done. If not, here’s how to install it on the major distros:

• Ubuntu / Debian: sudo apt install procps
• RHEL / CentOS / Fedora: sudo dnf install procps-ng
• Arch / Manjaro: sudo pacman -S procps-ng

Quick gotcha: vmstat lives in the procps-ng package. Don’t confuse it with the sysstat package, which provides iostat, sar, and mpstat. They’re related families of performance tools but separate installs. I’ve watched a coworker spend 20 minutes hunting for vmstat in sysstat docs — don’t be that person.

Basic Syntax and How vmstat Works

The syntax is dead simple:

vmstat [options] [delay [count]]

Three usage patterns cover almost everything I do day-to-day:

1. vmstat — single snapshot averaged since boot. Useful for nothing real-time. Ignore it.
2. vmstat 2 — sample every 2 seconds, forever. Ctrl+C to stop. This is what I run when something feels wrong.
3. vmstat 2 10 — sample every 2 seconds, then stop after 10 readings. Perfect for a quick 20-second snapshot.

For the full list of flags, see the official vmstat man page. But before you go flag-crazy, learn to read the default output — that’s where the real value is.

Reading vmstat Output: Column by Column

Here’s a typical output:

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 432156 198432 1234567    0    0    14    23  102  198  3  1 96  0  0

That’s a lot to absorb. Let me walk through each block.

Procs: r and b (run queue and blocked processes)

• r (runnable): Processes that are ready to run and waiting for CPU time. If r consistently exceeds your number of logical cores, your CPU is the bottleneck. On an 8-core box, r=10 means two processes are always queued up waiting for a slot. The r column is closely related to load average in Linux, but more immediate.
• b (blocked): Processes sleeping while waiting on I/O (usually disk). High b combined with high wa almost always means a storage bottleneck.

Memory: swpd, free, buff, cache

• swpd: Total virtual memory currently swapped to disk. Nonzero is not automatically a problem — old idle pages get swapped out and may sit there forever harmlessly. What matters is whether swap is being actively used, which is the si/so story below.
• free: Memory that’s truly idle. Linux deliberately keeps this low — empty RAM is wasted RAM. Don’t panic when free is small.
• buff: Kernel buffer memory, used for raw block-device reads.
• cache: Page cache holding file data. This is reclaimed instantly if applications need it — it is not “used up” memory. For a deeper look at how Linux really manages memory, see my guide on checking memory usage in Linux.

Swap: si and so (swap in and swap out)

• si (swap in): Memory pages read FROM swap into RAM, per second. Nonzero = the system is pulling data back out of swap. That’s memory pressure.
• so (swap out): Pages written TO swap from RAM, per second. Nonzero + climbing = your system is dumping memory to disk to stay alive. This kills performance.

If both si and so are nonzero in every line, you are swap thrashing. The free command will give you a more readable swap breakdown.

IO: bi and bo (blocks in and blocks out)

• bi: Blocks received from a block device (reads). Measured in 1024-byte blocks per second.
• bo: Blocks sent to a block device (writes), same units.

These tell you the system is doing disk work but not which disk. For per-device detail, pair vmstat with iostat.

System: in and cs (interrupts and context switches)

• in: Hardware and software interrupts per second. Modern systems easily hit thousands here without any problem.
• cs: Context switches per second — how often the CPU jumps between tasks. Normal range is hundreds to tens of thousands. A jump into hundreds of thousands per second often signals lock contention or a runaway thread pool.

CPU: us, sy, id, wa, st

• us: User CPU time %. Time spent running your applications. Stay under 70% for headroom.
• sy: System / kernel CPU time %. High sy means lots of syscalls — often a sign of heavy I/O or kernel work.
• id: Idle CPU %. The “doing nothing” time. If id is near 0 and wa is also low, the CPU is fully pegged.
• wa: I/O wait %. The CPU is idle because it’s waiting on disk. Anything above 20% is a red flag.
• st: Stolen time. Only appears inside virtual machines. Time the hypervisor stole from your VM to serve someone else. High st on a cloud VPS = you’re on a noisy host. For broader CPU diagnostics, see how to check CPU usage in Linux.

Essential vmstat Options with Examples

These are the flags I actually reach for, in order of frequency.

Continuous monitoring: vmstat 2 10

The single most useful daily command. Two-second intervals, ten readings, twenty seconds total. Watch the trend across lines, not any single number.

Megabyte output: vmstat -S M 2

Default output is in kilobytes, which is unreadable on modern systems with 16GB+ of RAM. -S M switches to megabytes. I have this aliased on every machine I touch.

Active and inactive memory: vmstat -a

Splits the memory column into active (recently used) and inactive (not used recently — candidate for swap). Useful when you suspect memory pressure but free still looks OK.

Add timestamps: vmstat -t 1 5

Adds a timestamp column to every line. Critical when you’re correlating performance spikes with cron jobs, deployments, or peak-traffic windows. This single flag has saved me hours.

Disk statistics: vmstat -d

Per-disk read/write totals — total reads, writes, merged operations, sectors, milliseconds spent. A great quick check before you reach for iostat.

Event summary: vmstat -s

Vertical dump of every memory counter since boot, one value per line. Perfect for shell scripts that need to log specific values without parsing the table format.

Slab cache stats: vmstat -m

Kernel slab cache usage, useful when you suspect kernel memory leaks. You’ll need root for this one.

What Bad vmstat Output Looks Like

Reading the columns is half the skill. The other half is recognizing the patterns. Here are the four I see most often.

CPU Bottleneck: high r, low id

Memory Pressure and Swap Thrashing: si/so consistently nonzero

I/O Bottleneck: high wa, high b

Context Switch Storm: very high cs

Real-World Troubleshooting with vmstat

Theory is great. Patterns are better. Let me show you exactly how I use vmstat when things are on fire.

Scenario 1: Server Is Slow — Start Here

SSH feels sluggish, an alert just fired, you’re logged in and panicking. First command: vmstat 2. Within 4 seconds you’ll know:

• If r > CPU count → CPU bound → htop next.
• If wa > 20% → I/O bound → check disks.
• If si/so > 0 → memory bound → check free and swap.

This three-way fork has resolved more incidents for me than any dashboard.

Scenario 2: Nightly Performance Drop — Timestamp Mode Reveals a Cron Job

A while back I had a customer-facing app that mysteriously slowed down every night around 2:14am. I ran vmstat -t 1 600 overnight in a tmux session. Next morning I scrolled through the timestamps and saw a clean spike at exactly 2:14:03 — wa shot up, bi went vertical. Cross-referenced cron logs and found a backup script someone had added without telling anyone. Without the -t flag I would’ve been guessing for hours.

Scenario 3: App Crashes After Heavy Load — Swap Thrashing Diagnosis

A Node.js app I was advising on kept getting OOM-killed under load. vmstat 2 told the whole story: swpd climbing every second, free at zero, so spiking into the thousands. Memory leak. We caught it with ps command sorted by RSS, found the culprit, and added monitoring. vmstat didn’t fix the leak — it pointed us at the right shelf in the right aisle.

Pairing vmstat with Other Linux Tools

vmstat is the dashboard warning light. These tools are the diagnostic gauges:

• vmstat → htop: vmstat says CPU is hot. htop says which process.
• vmstat → free -h: Cleaner memory breakdown with swap. Run after vmstat shows memory pressure.
• vmstat → iostat: vmstat shows I/O is happening. iostat -xz 2 shows on which device, with latency.
• vmstat → sar: For historical data — what happened at 3am yesterday. sar reads stored archives.
• vmstat → ps aux: When r is high, ps aux --sort=-%cpu | head finds the top consumers fast.

For longer-term visibility, I run a proper monitoring stack — see my walkthrough on setting up Prometheus and Grafana on Linux. For an even broader survey of what to install on a serious server, check out my roundup of the best Linux monitoring tools in 2026. The free-yet-comprehensive end of the spectrum is documented in Brendan Gregg’s Linux Performance tools overview — bookmark it.

Quick Reference: Most Useful vmstat Commands

Frequently Asked Questions

What does vmstat stand for?

vmstat stands for virtual memory statistics. Despite the name, it reports on far more than memory — CPU, swap, I/O, processes, and context switches all in one row.

Is vmstat installed by default on Linux?

On almost every mainstream distribution — Ubuntu, Debian, RHEL, Fedora, Arch — yes. It ships with the procps-ng package. If it’s missing, install procps (Debian-family) or procps-ng (Red Hat-family).

Why does the first vmstat line look weird?

Because it’s not real-time data. The first line is the average since the system was last booted. Only the second and subsequent lines reflect the actual sampling interval you specified.

What is a healthy I/O wait value in vmstat?

Under 5% is healthy on most workloads. 5-20% is suspect and worth investigating. Above 20% sustained almost always means a storage bottleneck.

What does the st column mean in vmstat?

“Stolen time” — the percentage of CPU time the hypervisor took away from your VM to serve other VMs on the same host. Nonzero st only appears inside virtual machines. High st on a VPS means you’re on a noisy neighbor and there’s nothing you can do from inside the VM.

Is vmstat better than top or htop?

They solve different problems. vmstat gives a system-wide one-line summary — perfect for spotting category of problem. top and htop show per-process detail — perfect for finding the specific culprit. Use vmstat first, then drill in with htop.

Wrapping Up: Make vmstat Muscle Memory

If you take one thing away: vmstat 2 should be the first command you run anytime a Linux box feels slow. It’s faster than opening a dashboard, more reliable than guessing, and it works on systems where you can’t install anything new. Memorize the patterns for CPU, memory, and I/O bottlenecks and you’ll diagnose problems in seconds instead of hours.

Once vmstat tells you the category, you’ll usually drill in with one of these next steps:

• CPU pegged? Read my deep dive on troubleshooting Linux CPU usage.
• Memory pressure? Walk through checking memory usage in Linux next.
• Looking for a long-term solution? My roundup of the best Linux monitoring tools in 2026 covers what to install for ongoing visibility.

If this guide saved you a 2am head-scratch, stick around — I write about Linux performance, sysadmin tooling, and homelab adventures every week. Subscribe to the newsletter and I’ll drop the next one straight in your inbox. Linux is more approachable than the gatekeepers want you to think, and small commands like vmstat are how you build the confidence to own your stack.

Alexa Velinxs

I'm Alexa Velinxs, a cryptocurrency trading expert passionate about demystifying digital assets for both beginners and seasoned investors. Through my writing, I share actionable strategies, market insights, and practical tips to help you navigate the crypto landscape with confidence. Let's explore the future of finance together.

See Full Bio