Mastering fio: How to Measure Linux Disk IOPS and Throughput Like a Pro – ITFROMZERO

Table of Contents

Why lscpu and hdparm aren’t enough for storage benchmarking?

Ever wondered why the dd command reports write speeds up to 500MB/s while your database still runs at a snail’s pace? When I first started out, I often used dd or hdparm for quick tests. Seeing those hundreds of MB/s made me confident the server was optimized. But reality is often harsher.

When deploying MySQL or PostgreSQL, systems start lagging despite plenty of remaining bandwidth. The problem: dd only measures sequential write speed. Real-world applications, however, demand high IOPS (Input/Output Operations Per Second) and extremely low Latency.

This is where fio (Flexible I/O Tester) comes in. It’s the industry-standard tool for accurately simulating complex R/W scenarios. I once used fio to prove a Cloud VPS provider was “overselling” resources. The results showed actual IOPS were only 1/3 of what was promised on their homepage. Since then, fio is always the first command I run on a new server.

Installing fio on Linux Distributions

Most popular distros have fio available in their standard repositories. Installation takes only a few seconds.

For Ubuntu or Debian:

sudo apt update && sudo apt install fio -y

For CentOS, RHEL, or AlmaLinux:

sudo yum install epel-release -y
sudo yum install fio -y

Run fio --version to check. If it shows version 3.x or higher, you’re ready to go.

Decoding Core Benchmarking Parameters

Don’t let long commands intimidate you. Focus on these “golden” parameters:

–direct=1: Forces fio to bypass the OS cache. You’ll measure actual hardware performance instead of RAM speed.
–rw: Test mode. Use randread/randwrite for IOPS and read/write for throughput.
–bs (block size): Data block size. Use 4k for IOPS (database standard) and 1M for throughput (large file copy standard).
–ioengine=libaio: I/O handling method. This is the most efficient choice on Linux.
–iodepth: Number of simultaneous requests. For NVMe SSDs, I usually set this to 32 or 64 to push the drive to its limits.

3 Real-World Benchmarking Scenarios

Here are the 3 commands I frequently use to “squeeze” every bit of performance out of a drive.

1. Measuring Random Read IOPS

This metric is vital for Web Servers and Databases.

fio --name=randread --ioengine=libaio --direct=1 --bs=4k --iodepth=64 --size=1G --runtime=60 --rw=randread --filename=testfile --group_reporting

We use bs=4k because most modern databases store data in similarly sized small blocks.

2. Measuring Sequential Write Throughput

Ideal if you’re running a video storage server, backups, or continuous log writing.

fio --name=seqwrite --ioengine=libaio --direct=1 --bs=1M --iodepth=16 --size=2G --runtime=60 --rw=write --filename=testfile --group_reporting

Here, I increase bs to 1M to allow data through a larger “pipe,” maximizing bandwidth.

3. Measuring Mixed Performance (Mixed R/W)

Simulates a real-world environment with 70% reads and 30% writes.

fio --name=mixed_rw --ioengine=libaio --direct=1 --bs=4k --iodepth=32 --size=1G --runtime=60 --rw=randrw --rwmixread=70 --filename=testfile --group_reporting

Reading the Results: Don’t Just Look at the Biggest Number

When fio finishes, don’t just celebrate high IOPS. Look at these three metrics:

IOPS: Operations per second. SATA SSDs are usually around 80k-100k; NVMe can reach millions.
BW (Bandwidth): Transfer speed (e.g., 500MiB/s).
lat (Latency): This is the real “performance killer.” Look at clat (completion latency). A high-quality NVMe SSD usually has latency under 200us (microseconds). If this number jumps to tens of milliseconds, the system will feel very sluggish.

Pro tip: Run the test at least 3 times at different times of the day. In the Cloud, performance is often affected by “noisy neighbors” sharing the same resources.

Tips to Prevent “Fake” Benchmark Results

After many incorrect benchmarks, I’ve learned a few survival rules:

Avoid testing on near-full drives: SSD performance drops significantly when free space is below 10-20% due to Garbage Collection mechanisms.
Test file must be larger than RAM: If the server has 16GB of RAM and you test a 1GB file, results will be unrealistically fast because the data fits entirely in the cache. Choose a --size that is large enough or always use --direct=1.
Be careful with paths: Never use --filename=/dev/sda unless you want to wipe your entire operating system. Point it to a specific file within a directory.

I hope these insights help you accurately assess your server’s power. fio is an excellent microscope for scrutinizing every detail of your storage system.