iotop for Disk IO Investigation

iotop shows per-process disk IO.

Usage

iotop is the per-process disk I/O equivalent of top. The tool surfaces which processes are doing disk I/O; the data drives investigation when disk seems to be the bottleneck. The discipline is reaching for iotop when symptoms suggest disk I/O is the issue.

What basic usage looks like:

• iotop -P shows per-process IO.: The -P flag aggregates I/O at the process level (rather than per-thread). The output is more readable; per-process attribution matches investigation needs.
• -o shows only active processes.: The -o flag filters to processes actively doing I/O. Processes with zero I/O are not displayed; the output focuses on what is contributing.
• Sort by I/O.: The default sort is by total I/O. The top of the list is the heaviest I/O processes; investigation focuses on these.
• Read and write columns.: Read I/O and write I/O are shown separately. Some processes are read-heavy; some are write-heavy; the distinction matters for diagnosis.
• Requires root.: iotop needs CAP_SYS_PTRACE; typically requires sudo. The privilege is the operational constraint.

Basic usage is straightforward. The tool is for the moment when disk I/O is suspect.

When

iotop is reached for when disk I/O is suspected. High disk utilization without obvious cause; slow database queries; unexplained latency. iotop surfaces the culprit process.

• Suspect disk-bound process.: Symptoms suggest disk is the bottleneck. iostat shows high utilization; latency is elevated; the cause is unclear from process-level metrics. iotop is the next investigative step.
• Surface the culprit immediately.: iotop's per-process attribution surfaces the heaviest I/O process. The data drives the next investigation: why is this process doing so much I/O?
• Database operations.: Heavy database operations (index rebuilds, batch operations, full table scans) often surface in iotop. The database process is the I/O-heavy contributor; the query level investigation follows.
• Logging-related I/O.: Logs being written, log rotation, log compression all produce I/O. iotop catches when these become significant; the team's logging configuration may need adjustment.
• Backup and replication.: Backup processes and replication agents do I/O. iotop shows when their I/O is interfering with primary workloads; the team adjusts schedules or resource allocation.

The when is straightforward. iotop is reached for when disk I/O is the question.

Alternatives

iotop is interactive; some scenarios benefit from non-interactive alternatives. pidstat fills this role; both tools have their place.

• pidstat -d 1 for non-interactive.: pidstat with the -d flag shows per-process disk I/O at one-second intervals. The output is non-interactive; suitable for scripting and recording.
• Both work.: Either tool produces the per-process I/O view. The choice is operational fit; the data is similar.
• Pick by use case.: Interactive investigation favors iotop; non-interactive recording or scripting favors pidstat. The team uses each where it fits.
• Continuous monitoring.: For continuous monitoring, neither iotop nor pidstat is the right tool. node_exporter or similar Prometheus exporters handle continuous I/O monitoring; iotop and pidstat are for ad-hoc investigation.
• Combine with iostat.: iostat shows overall disk activity; iotop or pidstat show per-process attribution. The combination diagnoses the question fully: is the disk busy, and which process is making it busy?

iotop for disk I/O is one of those Linux tooling skills that pays off in incident response. Nova AI Ops integrates with system telemetry, surfaces I/O patterns at scale, and complements the local-tool perspective for systematic investigation.