Monitor Linux Disk I/O with iostat and iotop

Disk performance problems can make a healthy Linux server feel broken. Applications may become slow, SSH sessions can pause, and users may report timeouts even when CPU and memory usage appear normal. On RHEL, CentOS, Fedora, and similar systems, iostat and iotop provide two useful views of storage activity.

iostat shows device-level statistics, including read and write rates, request sizes, queue depth, and time spent servicing I/O. iotop works at the process level, helping you identify which service is generating disk reads or writes. Used together, they turn a vague complaint about a “slow server” into measurable evidence.

These tools are especially useful for Australian organisations running workloads across Sydney or Melbourne data centres, AWS ap-southeast-2, and smaller regional offices. A database backup scheduled during business hours in Perth or Brisbane can create noticeable latency for users elsewhere, even when the application itself has not changed.

The examples below use common package names and commands for Red Hat-based systems. Run monitoring commands with care on production machines, and remember that a high I/O number is not automatically a fault: the meaning depends on the storage type, workload, and response time users expect.

Install the monitoring tools

The iostat command is supplied by the sysstat package. Install it with:

sudo dnf install -y sysstat

Older CentOS releases may use yum instead:

sudo yum install -y sysstat

iotop is installed separately:

sudo dnf install -y iotop

Confirm that both commands are available:

iostat --version
sudo iotop --version

On some systems, iotop requires root privileges to inspect process I/O. If the command reports insufficient permissions, start it with sudo. Package availability can vary between repositories, so check that the relevant RHEL, CentOS Stream, or Fedora repositories are enabled before troubleshooting the installation.

Read device statistics with iostat

Start with a compact report that refreshes every two seconds:

iostat -xz 2

The -x option displays extended statistics, while -z hides devices with no activity. Important columns include %util, await, r/s, w/s, rkB/s, and wkB/s. %util indicates how busy a device was during the interval. await represents average request time, including time spent waiting in the queue.

A device showing high %util and rising await may be saturated. However, SSDs and NVMe devices can handle very different workloads from spinning disks, and cloud volumes may have burst or throughput limits. A busy disk serving a large sequential backup may be healthy, while a modest random workload with a high wait time can cause application trouble.

For a report covering a fixed number of samples, use:

iostat -xz 2 5

The first report often includes averages since boot, so focus on later intervals when investigating a current incident. This is useful during a scheduled backup window, such as when an Australian retailer runs overnight processing before the morning shift begins.

Find busy processes with iotop

iotop provides a live process view:

sudo iotop

For a simpler display containing only active processes, use:

sudo iotop -o

Useful columns include DISK READ, DISK WRITE, and total I/O. Press r or w inside the interactive screen to change sorting, depending on the installed version. Press q to exit. A process such as mysqld, postgres, rsync, tar, or a backup agent may immediately stand out.

For a batch-style capture suitable for incident notes, run:

sudo iotop -b -n 3 -d 2

This records three snapshots at two-second intervals. Avoid blaming the first process you see: kernel flushers, journaling, and delayed writes can make the process responsible for the original write appear separately from the process creating the final device activity.

Connect I/O symptoms to services

When iostat reports high latency, compare the affected device with its mount point:

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
df -hT

Then inspect service activity and recent logs:

systemctl --type=service --state=running
sudo journalctl --since "15 minutes ago"

A full filesystem, runaway log file, failed rotation job, or database maintenance task can all create unusual write pressure. Check inode usage as well:

df -ih

For database servers, examine checkpoints, temporary tables, transaction logs, and backup jobs. For web servers, review access logs and cache directories. Nginx may appear quiet while a separate compression or log-processing process generates the heavy writes. If the host serves customers in Sydney and Perth, compare application response times with the exact periods shown by iostat.

Administrators preparing for technical interviews can reinforce this workflow through practical Linux interview questions, especially those covering load, storage latency, and process diagnosis.

Build a repeatable investigation

Begin by recording a baseline during normal operation:

iostat -xz 60 10 | tee /tmp/iostat-baseline.txt

Capture the same information during the slowdown, then compare %util, await, throughput, and request rates. A sudden increase in await with similar throughput suggests contention or queueing. A large increase in writes may point to backups, logs, temporary files, or a batch job.

Keep the checks lightweight and time-bounded. iotop is excellent for live diagnosis, but it is not a long-term monitoring system. For recurring incidents, collect historical metrics with tools such as sar, collectd, or an established monitoring platform. This is valuable for Australian hosting environments where storage performance can change during shared-cloud demand or scheduled maintenance.

Do not rely on a single metric. Correlate disk statistics with vmstat, memory pressure, CPU wait time, filesystem capacity, and application logs:

vmstat 2 5
free -h

A practical diagnosis should identify the device, the waiting process, the time window, and the likely workload before any configuration change is made.

Use iostat -xz 2 to establish the current storage baseline, then run sudo iotop -o during the next slowdown and record the busiest process alongside its mount point.