Skip to content

Monitoring System Health with vmstat

The vmstat (virtual memory statistics) command provides a concise, real-time view of your Chromebook’s processes, memory, swap, I/O, interrupts, context switches, and CPU usage. It’s ideal for quick health checks and for spotting trends like memory pressure, swap churn (zram), or I/O bottlenecks—all from crosh.

Usage

vmstat [options] [delay [count]]
  • delay: Refresh interval (seconds) between reports.
  • count: Number of reports to print before exiting.
  • Without delay, vmstat prints a single summary since boot plus one immediate sample and exits.

Common Options

  • -a — Show active/inactive memory instead of buffers/cache.
  • -s — Display a table of memory and system event counters.
  • -m — Show slab cache statistics.
  • -n — Do not reprint the headers on each line.
  • -d — Show disk statistics summary.
  • -D — Show overall (aggregate) disk statistics.
  • -p <device> — Show partition statistics for a device (e.g., mmcblk0p1).
  • -S <K|M|G> — Set units (kibibytes by default).
  • --wide — Do not truncate output columns.

Availability of some flags may vary by ChromeOS version and device image.

Quick Starts

1) One-second live view (5 samples)

vmstat 1 5
Good for a brief snapshot of run-queue pressure, memory, and CPU mix.

2) Focus on active/inactive memory

vmstat -a 2 10
Swaps buff/cache columns for active/inact to see page activity trends.

3) Human-friendlier units

vmstat -S M 1 5
Reports memory columns in MiB.

4) Event counters at a glance

vmstat -s
Great for total page ins/outs, context switches, and interrupts since boot.

5) Slab caches (kernel allocators)

vmstat -m
Useful when tracking kernel memory fragmentation or growth over time.

6) Disk/partition summaries

vmstat -d
vmstat -D
vmstat -p mmcblk0p1
On many Chromebooks, internal storage is mmcblk0; external USB may appear as sda, etc.

Interpreting the Standard Output

A typical vmstat 1 line (columns may vary by build):

  • procs
  • r: Runnable processes (run queue length). Values > CPU cores for sustained periods = saturation.

  • b: Processes blocked (usually waiting on I/O or memory).

  • memory

  • swpd: Amount of swap used (ChromeOS commonly uses zram).
  • free: Completely unused memory.
  • buff: Buffers used by kernel.

  • cache: Page cache (file-backed). High cache with low free is usually fine.

  • swap

  • si: Swap in (KB/s). Persistent non-zero values can indicate memory pressure.

  • so: Swap out (KB/s). Watch for spikes alongside UI sluggishness.

  • io

  • bi: Blocks received from block device (reads).

  • bo: Blocks sent to block device (writes).

  • system

  • in: Interrupts per second.

  • cs: Context switches per second.

  • cpu (percentages of total CPU time)

  • us: User time (apps).
  • sy: System time (kernel).
  • id: Idle time.
  • wa: I/O wait (time CPU is idle waiting for I/O).
  • st: Time “stolen” by the hypervisor (typically 0 on bare metal; can appear with VMs).

ChromeOS-Specific Notes

  • zram swap: ChromeOS commonly uses compressed RAM swap; moderate swpd is normal. Sustained high si/so may signal insufficient memory for your workload.
  • ARCVM & Crostini: Android (ARC) and Linux containers/VMs (Crostini) can influence memory pressure and CPU usage. Correlate vmstat with ARC and container tools when diagnosing app issues.
  • Network diagnostics: If performance issues correlate with wa increases, pair vmstat with network tools like tracepath or HTTP/DNS checks to rule out network-induced stalls.
  • End-to-end troubleshooting: When resource issues coincide with VPN usage, validate tunnels and MTU (e.g., WireGuard) to prevent packet fragmentation/latency that can elevate wa.

Practical Workflows

Diagnose Memory Pressure While Browsing

# Watch system while reproducing a slow tab switch
vmstat -a 1 20

# Then inspect cumulative counters
vmstat -s
Look for elevated si/so along with growing active and shrinking free.

Separate I/O Wait from CPU Saturation

vmstat 1 10
- High wa with low r → I/O bottleneck (storage or network).
- High r with low wa → CPU-bound (too many runnable tasks).

Pair with Network Path Checks

vmstat 1 10      # watch wa/in/cs
tracepath example.com
If wa spikes while tracepath shows long hops or loss, the stall may be upstream.

When Android Apps Misbehave

vmstat 1 15
# In parallel, use ARC diagnostics for app-specific stats
# (see 'arc stats traffic', 'arc meminfo', etc.)
Use ARC tools to pinpoint an app overwhelming memory or network.

Best Practices

  1. Prefer trends over single snapshots
    Run with a delay (e.g., vmstat 1 30) to observe patterns rather than one-off spikes.

  2. Correlate symptoms
    Combine vmstat with targeted network checks (tracepath, DNS/HTTP) and service tooling (e.g., WireGuard) to isolate root causes.

  3. Mind containers/VMs
    ARCVM and Crostini share host resources; heavy workloads inside them will reflect in host vmstat. Use ARC/Crostini-specific tools to drill down.

  4. Capture and compare
    Save outputs during incidents to compare against normal baselines. Short bursts can miss critical behavior; capture at least 30–60 seconds.

  5. Check units
    Use -S M when sharing reports to avoid confusion over kibibytes vs mebibytes.

Example Output (What to Look For)

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0  131072  82000  12000 450000    0   12    34    28  220 1020 12  6 78  4  0
  • so > 0 with falling free → swapping out; consider closing tabs/apps.
  • wa rising with bi/bo spikes → storage pressure (updates, downloads, or container I/O).
  • High cs + r > cores → heavy multitasking; CPU contention.