iostat

What it does

iostat reports CPU utilization and, more importantly, per-device I/O statistics: reads/writes per second, throughput, average request size, queue depth, and (with -x) latency and utilization percentages. It's part of the sysstat package and is the standard tool for figuring out which disk is busy, how busy it is, and whether requests are queuing up — turning a vague "the app feels slow" complaint into a concrete "disk sdb is at 98% utilization with 40ms average wait."

Beginner examples

• iostat — print one CPU + device report, averaged since boot
• iostat 1 — print a fresh report every 1 second, continuously
• iostat 2 5 — print 5 reports at 2-second intervals, then stop
• iostat -d — show only the per-device report, skipping the CPU summary

iostat 1 5

Advanced examples

• Get the full diagnostic picture per device: iostat -x 1 (adds %util, await, svctm, average queue size)
• Focus on one busy disk to watch it in isolation: iostat -x -p sda 1
• Report sizes in megabytes instead of default 512-byte blocks: iostat -d -m 1
• Include LVM/device-mapper volumes explicitly: iostat -N 1
• Log extended stats to a file during a load test for later review: iostat -x 5 > io_report.log &

iostat -x 1 5

Common mistakes

• Reading the first report as "current" state — like vmstat, it's a since-boot average; meaningful live data starts from the second report onward when an interval is given.
• Looking only at %util and ignoring await — a device can show high %util on a single-queue-depth workload that's still fast, while await tells you actual latency users would feel.
• Not installing sysstat first; iostat isn't part of a minimal base install on many distributions and containers.
• Comparing raw block counts across systems with different block/sector sizes instead of normalizing with -k or -m for consistent units.

Tips

• Always reach for -x (extended stats) in real investigations; the basic report lacks await and %util, which are usually the two most actionable numbers.
• Watch %util per device to find which physical disk is the bottleneck when a system has multiple mounted volumes.
• A high await with low %util can indicate a slow or misbehaving storage backend (e.g. network storage) rather than raw device contention.
• Use -p <device> to break a device's stats into its partitions when you need to know which partition is driving the I/O.

Best practices

• Prefer iostat -x <interval> over the plain report in any real troubleshooting session; the extra columns are almost always what you end up needing.
• Normalize units with -k or -m in scripts and reports so numbers are comparable across different systems and iostat versions.
• Correlate iostat device names (sda, nvme0n1, dm-0) with lsblk/mount output so you know which filesystem or LV a hot device backs.
• Sample over a representative time window (multiple intervals) rather than a single report, since disk I/O is often bursty.

Real-world use cases

• Root-causing a database performance issue by checking whether the data disk is at high %util/await during slow query periods.
• Verifying that moving a workload to faster storage (e.g. spinning disk to SSD, or local to attached network volume) actually reduced await times.
• Capacity planning for storage: tracking %util trends over weeks to decide when a volume needs to be upgraded or the workload rebalanced across disks.

Common interview questions

• What do %util and await mean in iostat -x output? %util is the percentage of time the device had at least one I/O request outstanding (device busy time); await is the average time, in milliseconds, an I/O request took including queueing — the more direct measure of latency users would notice.
• How would you find out which disk is the bottleneck on a multi-disk server? iostat -x 1 and compare %util/await across the listed devices; the one sustained near 100% util or with high await is the bottleneck.
• What package provides iostat and what's it commonly paired with? The sysstat package, commonly used alongside mpstat (CPU) and vmstat (overall system) for a full picture during performance investigations.