How to Use iotop in Linux: Monitor Disk I/O Per Process Like a Pro

If you’ve ever stared at a Linux server that feels slow as molasses while top swears the CPU is barely doing anything, you already know the frustration that taught me how to use iotop in Linux. Disk I/O is the silent killer of server performance. CPU and memory tools won’t show you a thing about it. That’s where iotop earns its keep — it shows you, in real time, exactly which process is hammering your disk.

In this guide, I’ll walk you through installing iotop, reading its output, the flags I actually use day to day, and a few real-world troubleshooting workflows pulled straight from my own homelab. There’s also one flag that fixed a mystery slowdown on my Proxmox box at 2am — I’ll get to that in section six.

What Is iotop and Why You Need It

iotop is to disk what top command is to CPU. It’s an interactive, real-time monitor — except instead of showing CPU and memory per process, it shows disk read and write rates per process. That’s a huge gap that htop, top, and most general monitoring tools leave wide open.

Get a VPS from as low as $11/year! WOW!

Here’s the part that bites people: when a server feels sluggish but CPU usage looks fine, the culprit is almost always disk I/O. The system is waiting on the storage to keep up. Top will happily show you 5% CPU usage while your application crawls because every read is queuing behind a runaway backup job.

iotop fills that blind spot. It reads kernel task accounting data, which is why you’ll always need sudo or root to run it. Pair it with a tool to check disk usage in Linux and you’ve got both the “how full” and “how busy” sides covered.

Personal moment: I run a Proxmox homelab, and one summer my VMs started lagging every night around 2am. htop showed nothing wrong. I almost rebuilt the whole storage pool out of frustration before someone on the forums said the magic words: “run iotop.” Two minutes later I had my answer. (More on that disaster in a bit.)

How to Install iotop on Linux

iotop isn’t installed by default on most distros. The good news: every major package manager has it. Here’s how to grab it on the big four families.

Debian and Ubuntu

sudo apt update
sudo apt install iotop

RHEL, CentOS, AlmaLinux, Rocky

# RHEL/CentOS 7
sudo yum install iotop

# RHEL 8+, AlmaLinux, Rocky
sudo dnf install iotop

Fedora

sudo dnf install iotop

Arch Linux

sudo pacman -S iotop

(And yes, BTW I use Arch.)

A Note on iotop-c for Newer Kernels

This one trips up a lot of folks on modern systems. The original iotop is a Python script, and it’s had compatibility issues with Linux kernel 5.14 and later. If you run it on Ubuntu 22.04+ or Fedora 36+ and see weird errors or empty output, switch to iotop-c — a C rewrite that handles modern kernels properly.

sudo apt install iotop-c
# or
sudo dnf install iotop-c

I lost an embarrassing amount of time to this before I figured it out. If iotop is acting strange on a fresh distro install, iotop-c is the fix.

How to Read the iotop Output

The first time you fire up sudo iotop, the columns can look like alphabet soup. Here’s what each one actually means:

• TID: The thread ID (use -P to show PIDs instead).
• PRIO: The I/O scheduling priority class and level.
• USER: Who owns the process.
• DISK READ: Current read bandwidth, in KB/s or MB/s.
• DISK WRITE: Current write bandwidth.
• SWAPIN: Percent of time spent waiting on swap. Should be near 0 on a healthy system.
• IO>: The percentage of time the process spent doing I/O. This is the column you watch.
• COMMAND: The process name and arguments.

Up top you’ll also see two summary lines: Total DISK READ / WRITE is the aggregate across all processes, while Actual DISK READ / WRITE shows what’s truly hitting your storage hardware. Those numbers differ because of caching, buffering, and the magic the kernel does behind the scenes.

Essential iotop Flags You’ll Actually Use

The man page lists a small army of flags. Here are the ones I lean on every week. For the complete reference, check the official iotop man page.

Show Only Active I/O Processes (-o)

This is the flag you’ll use 90% of the time. It hides idle processes and shows only ones currently moving bytes:

sudo iotop -o

If I had to pick one iotop command for life, it would be this one.

Batch Mode for Logging and Scripts (-b, -n, -t)

Batch mode makes iotop non-interactive — perfect for piping into logs, grep, or capturing snapshots for later.

sudo iotop -b -o -d 5 -n 12 -t | tee /tmp/io_log.txt

That captures a 60-second window (12 snapshots at 5-second intervals) with timestamps, and writes it to a file. Combine the output with journalctl entries and you can reconstruct exactly what happened during an incident.

Filter by User or PID (-u, -p)

sudo iotop -u postgres      # only postgres user
sudo iotop -p 12345         # only PID 12345

Accumulated I/O Mode (-a)

This is the underrated flag. By default, iotop shows current bandwidth — which misses bursty processes that read 500MB in two seconds and then go quiet. -a shows totals since iotop started, so you can catch those spikes after the fact.

Show Processes Only, Not Threads (-P)

Threads are useful but noisy. -P rolls them up into their parent process for a cleaner view.

Interactive Keyboard Controls

Once iotop is running, you don’t need to quit and relaunch with different flags. The interactive controls cover most of them:

• o: Toggle the “only active I/O” filter (same as the -o flag).
• p: Toggle current vs accumulated bandwidth view.
• a: Toggle accumulated I/O mode.
• q: Quit iotop.
• Left/right arrows: Change the sort column.
• r: Reverse the sort order.
• ?: Show the help screen.

Real-World Troubleshooting Scenarios

This is the section where iotop actually earns its keep. Three scenarios pulled straight from my own logs.

Finding the Process Hammering Your Disk During a Slowdown

Remember that 2am Proxmox mystery I teased earlier? Here’s the punchline. My VMs were crawling, top showed clean CPU, and memory was nowhere near full. I SSH’d in and ran:

sudo iotop -o

Within five seconds I saw it: an rsync process sustained at 120 MB/s write, owned by my backup user. I had set up an offsite backup script weeks earlier and completely forgotten to apply ionice limits. Every night at 2am, it was saturating my storage pool’s write bandwidth. Two minutes of iotop saved me hours of guessing. Lesson learned — and now I treat any automatic backups on Linux setup like a loaded gun until I’ve checked its I/O profile.

Capturing a 60-Second I/O Snapshot for Later Analysis

When a slowdown is intermittent, you can’t always be at the keyboard. Schedule this as a cron job or fire it during a suspected incident:

sudo iotop -b -o -t -n 60 -d 1 | tee /var/log/io-capture.txt

That gives you a one-minute, timestamped log. Once you have a suspect PID, drop into lsof with lsof -p PID to see exactly which files it’s touching. For even deeper inspection, strace will show you every system call.

Diagnosing a Slow Database Server

On database servers, watch for sustained DISK WRITE from mysqld, postgres, or mariadbd. Common culprits: vacuum/autovacuum, large transaction commits, or checkpoint floods. If a runaway service is the cause, systemctl can stop or restart it. Pair iotop with du command to see which directories are growing and df command to confirm you’re not also out of free space.

iotop vs iostat vs vmstat: Which Tool When?

“Requests which involve disk I/O can be slowed dramatically if CPUs need to wait on the disk to read or write data.” — Red Hat’s documentation on I/O performance factors

Each tool answers a different question. Here’s the cheat sheet I keep pinned to my monitor:

My standard workflow: vmstat to detect → iotop to identify → lsof to confirm. For the full mental model, Brendan Gregg’s Linux performance tools reference and his USE Method (Utilization, Saturation, Errors) are gold-standard reading.

Common iotop Errors and Fixes

“CONFIG_TASK_IO_ACCOUNTING not enabled”

The kernel is missing task I/O accounting support. Almost every modern distro kernel has it, but if you’re on an ancient build, upgrade or rebuild with the option enabled. Easier: switch to iotop-c, which handles this gracefully.

“Permission denied”

You forgot sudo. iotop always needs root.

iotop shows 0.00 B/s for everything

Toggle accumulated mode with a to see if any I/O is happening at all. If everything still reads zero, the kernel may not be exposing accounting data — install iotop-c.

Python iotop crashes on kernel 5.14+

This was my exact issue on Ubuntu 22.04. The original Python iotop hasn’t been updated to handle changes in /proc/PID/io on newer kernels. Install iotop-c and the problem disappears.

“iotop: command not found”

It’s not preinstalled. Run the right install command for your distro from section two.

Wrapping Up

Once you’ve used iotop to crack one mystery slowdown, you’ll wonder how you ever monitored a Linux server without it. The flag you’ll reach for most is -o. The flag that’ll save you when an incident is already over is -a. And the package you’ll want on modern kernels is iotop-c. That’s 80% of what you need.

If you want to go deeper on the broader monitoring story, my roundup of the best Linux monitoring tools for 2026 covers everything that pairs well with iotop, and my guide to Linux disk usage analyzers complements the real-time view with deeper storage analysis.

Got a server that’s acting weird? Don’t waste an afternoon staring at top. Run sudo iotop -o first and let your disk tell you what’s wrong. Then come back and let me know what process it caught red-handed — these stories are why I write these guides in the first place.