Testing Disk Read/Write Speed on CentOS with dd

Testing Disk Read/Write Speed on CentOS with dd

Databases, logs, and caches are all I/O-intensive workloads where disk speed directly affects request latency. The "500MB/s" a vendor claims on the spec sheet often does not match what you actually measure, so a quick dd sanity check before going to production is worth it. dev is the mounted disk directory (for example /www or /data), and the test file is written into that directory. The three commands below cover write, read, and small-block synchronous write.

Even without lab-grade precision, dd answers "can this disk handle my current workload": for database transactions and log flushes, the bottleneck is almost always synchronous write speed.

1. Test Write Speed

dd if=/dev/zero of=/test.bin bs=1M count=256 conv=fsync

• if=/dev/zero: read from the zero device (produces all-zero data);
• of=/test.bin: write to the test file;
• bs=1M: read/write 1M at a time;
• count=256: read/write 256 times, producing a 256M test file;
• conv=fsync: physically sync before counting, to avoid inflated memory cache numbers.

2. Test Read Speed

dd if=/test.bin of=/dev/zero bs=1M count=256 iflag=direct

• iflag=direct: bypass the filesystem cache and read directly from disk, producing results closer to real disk read performance.

3. Test Synchronous Write Speed (Small Blocks)

dd if=/dev/zero of=/test.bin bs=64k count=1k oflag=dsync

• bs=64k: write 64K each time;
• count=1k: write 1024 times, 64M in total;
• oflag=dsync: sync to disk on every write, simulating a real small-file write scenario; the speed will be noticeably lower than the cached write above.

How to tell whether the result is normal

Different media differ widely in speed; here is a reference range:

If a disk marketed as SSD measures only tens of MB/s, you probably bought a shared-I/O or rate-limited instance, or the load was too high during the test. Fast reads with slow writes usually reflect write-cache policy or firmware differences and are acceptable; if reads and writes are both more than double the baseline for the same SKU, contact the vendor.

Bonus: hdparm read test

If you only want a quick look at read capability, hdparm is lighter:

yum install -y hdparm
hdparm -t /dev/vda1

-t measures buffered reads, -T measures cache reads. Note that hdparm needs root and only works on block devices, not mounted directories.

Why run fio too

dd is simple and intuitive, but it only measures sequential reads/writes, not random IOPS. For capacity planning in production, use fio:

fio --name=randwrite --rw=randwrite --bs=4k --size=1G --numjobs=4

fio covers random read/write, mixed workloads, and latency distribution, matching a database's real load much more closely — a good next step after dd. Watch disk space while running it: --size=1G creates a 1GB test file, so point it at the target mount and clean up afterward.

When and where to test

Think about the goal before testing. For a "physical exam" of a new cloud host, run it once on both the system disk and the data disk; for a database migration evaluation, test the data disk attached to the target instance, not the system disk — they are often not the same physical disk. Avoid business peaks; run in the early morning or a low-traffic window, repeat three times, and take the median.

A common question is "it measured slow — should I return it?" First classify the media against the reference ranges above, then check for throttling: cheap cloud instances often share host I/O, and a rate far below the advertised figure is usually a limited SKU rather than a bad disk.

Example Output

1073741824 bytes (1.1 GB) copied, 4.63867 s, 231 MB/s

The final 231 MB/s is the measured read/write speed. Note that dd measures sequential read/write speed and is affected by CPU, filesystem, and disk cache policy, so results may vary slightly between runs on the same disk — run it three times and take the median.

Also keep units straight: dd reports decimal MB/s (1 MB = 1,000,000 bytes), and most vendors use decimal too, so they compare directly; if a vendor quotes binary GiB, the number looks "smaller" — normalize before concluding.

Notes

Testing is easy; leaving behind a mess is not. Follow these and you will stay out of trouble:

1. Remember to delete the test file after testing to avoid wasting disk space:

   rm -f /test.bin
   

2. Test when the server load is low for more accurate results;

3. conv=fsync and oflag=dsync trade some speed for more realistic disk data, which is exactly what we want;

4. The test file lands on whichever mount point you point it at, so change the path when switching disks;

5. Record the synchronous-write result before deleting the test file so you can compare it after swapping disks or scaling up.

Disk performance testing is an important part of server performance testing. For more server operations and performance optimization content, see the cloud servers category.

Original post: https://www.cnblogs.com/cqzhuomi/articles/17284297.html (cnblogs.com CQZHUOMI, repost)
Reference: fio docs — https://fio.readthedocs.io ; Red Hat performance docs — https://access.redhat.com/documentation/