vmstatReport CPU, memory, swap and I/O activity over time
vmstat prints one compact line per interval: run queue, blocked tasks, memory, swap in/out, block I/O, interrupts, context switches and the CPU split. In a few seconds it tells you whether a slow box is short of CPU, memory or disk.
vmstat [-S M] [-w] [-t] [DELAY [COUNT]] vmstat -s | -dThe API is slow. Check, second by second, whether the CPUs are the bottleneck.
vmstatprocps-ng vmstat: reads /proc/stat, /proc/meminfo and /proc/vmstat each interval.
vmstat reads kernel counters and prints the differences between samples. procs r and b come from /proc/stat (procs_running and procs_blocked: runnable tasks and tasks in uninterruptible sleep). Memory comes from /proc/meminfo. si/so (KiB/s swapped in from and out to disk) and bi/bo (blocks per second read from and written to block devices, 1 KiB units) come from /proc/vmstat counters. in and cs are interrupts and context switches per second; us, sy, id, wa, st and gu are percentages of CPU time, from the tick counters in /proc/stat. The first line is special: it is averaged since boot, so ignore it when diagnosing a current problem. vmstat costs almost nothing to run, which makes it safe on a box that is already struggling.
DELAY [COUNT]Print every DELAY seconds, COUNT times (first line = since boot)-S MMemory columns in MiB (k, K, m, M allowed)-wWide output: wider columns that don't overflow-tTimestamp on every line-aShow active/inactive memory instead of buff/cache-sOne-off table of memory and event counters-dPer-disk read/write statistics-ySkip the since-boot first lineReading the first line of vmstat 1 as the current stateThe first line is an average since boot, often calm, while the problem is happening now.
Skip it, or use vmstat -y 1Panicking at a non-zero swpdswpd is how much is sitting in swap, possibly idle pages from days ago. That alone doesn't slow anything.
Watch si/so: sustained swap traffic is what hurtsExpecting bi/bo in megabytesbi and bo are blocks per second, 1 KiB blocks on Linux. 180000 means about 180 MB/s.
Divide by 1024 for MiB/s, or use iostat -mComparing r with 1 instead of with the CPU countr is the number of runnable tasks; a 16-CPU box can run 16 at once without queueing.
Sustained r above nproc means CPU saturationTry these on a Linux machine of your own. Each task has a hint and a solution.
Print 5 vmstat samples, one per second, with memory in MiB.
Run vmstat for 3 samples without the since-boot line and with timestamps.
Show the one-off summary of memory and event counters, and find how many forks happened since boot.
Generate CPU load with `yes > /dev/null &` and watch r and us change in vmstat. Then stop it.
vmstatReport CPU, memory, swap and I/O activity over time
vmstat prints one compact line per interval: run queue, blocked tasks, memory, swap in/out, block I/O, interrupts, context switches and the CPU split. In a few seconds it tells you whether a slow box is short of CPU, memory or disk.
vmstat [-S M] [-w] [-t] [DELAY [COUNT]] vmstat -s | -dThe API is slow. Check, second by second, whether the CPUs are the bottleneck.
vmstatprocps-ng vmstat: reads /proc/stat, /proc/meminfo and /proc/vmstat each interval.
vmstat reads kernel counters and prints the differences between samples. procs r and b come from /proc/stat (procs_running and procs_blocked: runnable tasks and tasks in uninterruptible sleep). Memory comes from /proc/meminfo. si/so (KiB/s swapped in from and out to disk) and bi/bo (blocks per second read from and written to block devices, 1 KiB units) come from /proc/vmstat counters. in and cs are interrupts and context switches per second; us, sy, id, wa, st and gu are percentages of CPU time, from the tick counters in /proc/stat. The first line is special: it is averaged since boot, so ignore it when diagnosing a current problem. vmstat costs almost nothing to run, which makes it safe on a box that is already struggling.
DELAY [COUNT]Print every DELAY seconds, COUNT times (first line = since boot)-S MMemory columns in MiB (k, K, m, M allowed)-wWide output: wider columns that don't overflow-tTimestamp on every line-aShow active/inactive memory instead of buff/cache-sOne-off table of memory and event counters-dPer-disk read/write statistics-ySkip the since-boot first lineReading the first line of vmstat 1 as the current stateThe first line is an average since boot, often calm, while the problem is happening now.
Skip it, or use vmstat -y 1Panicking at a non-zero swpdswpd is how much is sitting in swap, possibly idle pages from days ago. That alone doesn't slow anything.
Watch si/so: sustained swap traffic is what hurtsExpecting bi/bo in megabytesbi and bo are blocks per second, 1 KiB blocks on Linux. 180000 means about 180 MB/s.
Divide by 1024 for MiB/s, or use iostat -mComparing r with 1 instead of with the CPU countr is the number of runnable tasks; a 16-CPU box can run 16 at once without queueing.
Sustained r above nproc means CPU saturationTry these on a Linux machine of your own. Each task has a hint and a solution.
Print 5 vmstat samples, one per second, with memory in MiB.
Run vmstat for 3 samples without the since-boot line and with timestamps.
Show the one-off summary of memory and event counters, and find how many forks happened since boot.
Generate CPU load with `yes > /dev/null &` and watch r and us change in vmstat. Then stop it.