Linux 存储性能测试：fio、dd 与 bonnie++ 评估磁盘读写性能

一、存储性能测试的前菜认知

在给服务器做体检时，存储系统就像血管网络，它的畅通程度直接决定业务系统的生命体征。当我们需要验证SSD的实际吞吐量、排查机械硬盘的瓶颈，或者比较不同RAID阵列的效能时，常用的三把"听诊器"就是本文要重点讨论的：

• fio：配置复杂的全科医生
• dd：快诊快治的急诊大夫
• bonnie++：做全面体检的化验科室

这套组合拳用得好，不仅能找出慢如蜗牛的文件操作，还能揪出隐藏的性能吸血鬼。以下测试环境统一采用Ubuntu 22.04 LTS系统，被测磁盘是挂载在/mnt/test目录的NVMe SSD。

二、性能测试工具全家桶尝鲜

2.1 极简主义代表：dd命令

虽然常被戏称为"disk destroyer"，但合理使用dd命令进行快速基准测试的场景依然广泛存在：

# 测量顺序写入速度（注意必须用iflag=direct跳过缓存）
dd if=/dev/zero of=/mnt/test/testfile bs=1G count=10 oflag=direct

# 测试顺序读取速度（搭配无意义运算验证数据完整性）
dd if=/mnt/test/testfile of=/dev/null bs=1M iflag=direct

执行结果解读示例：

10485760000 bytes (10 GB, 9.3 GiB) copied, 5.21328 s, 2.0 GB/s

该输出显示在跳过缓存的情况下，SSD的持续写入速度达到2GB/s。但请注意，dd命令有几个"经典坑位"：

1. 测试文件需3倍于内存大小 避免缓存干扰
2. 多次采样取均值 规避瞬间波动
3. 勿在已用分区操作 可能误删生产数据

2.2 精密仪器：fio参数化测试

当需要模拟MySQL的随机读写、Kafka的日志追加等复杂场景时，fio的参数化能力就大显身手了：

# mixed_rw.fio 混合读写场景配置文件
[global]
directory=/mnt/test
size=20G
runtime=300
ioengine=libaio
iodepth=32
numjobs=4
group_reporting

[rand-read]
rw=randread
bs=4k
stonewall

[seq-write]
rw=write
bs=128k
stonewall

[rand-rw]
rw=randrw
rwmixread=70
bs=4k
stonewall

执行命令及参数解析：

# 启动四线程混合测试，输出JSON格式报告
fio mixed_rw.fio --output-format=json --output=mixed_result.json

# 结果处理建议
jq '.jobs[] | {jobname: .jobname, read_iops: .read.iops, write_iops: .write.iops}' mixed_result.json

关键参数解密：

• iodepth=32：模拟高并发队列深度
• numjobs=4：设置并行工作线程数
• rwmixread=70：70%读+30%写的混合比例

实测案例片段：

"rand-read": { "iops": 98532 },
"seq-write": { "bw_bytes": 2147483647 },
"rand-rw": { "read_iops": 67412, "write_iops": 29543 }

这样的数据可以直接换算为业务系统的TPS/QPS容量。

2.3 全能健检：bonnie++

针对文件系统综合性能，bonnie++能给出六维评估报告：

# 创建10GB测试文件，16线程并发测试
bonnie++ -d /mnt/test -s 10G -n 0 -m TEST_LABEL -f -u root

输出解析重点：

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   16     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
TEST_LABEL     64  99MB/s  10GB/s   8.7GB/s   42MB/s  15GB/s 15234.6

各字段对应能力：

• 顺序输出：大数据块写入性能
• 重写能力：现有文件修改效率
• 随机寻道：文件系统元数据操作速度

在EXT4 vs XFS的对比测试中，我们发现当小文件占比超过30%时，XFS的随机寻道性能平均比EXT4高17%，但在顺序写入场景下EXT4仍保持5%的优势。

三、实战中的兵器谱对决

3.1 典型应用场景对照表

3.2 工具特性五维雷达图

从五个维度进行对比（5分为满分）：

              灵活性  易用性  精度  多维度  安全性
fio          ⭐⭐⭐⭐⭐   ⭐⭐     ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐   ⭐⭐⭐
dd           ⭐        ⭐⭐⭐⭐⭐ ⭐⭐      ⭐        ⭐
bonnie++     ⭐⭐      ⭐⭐⭐    ⭐⭐⭐⭐   ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐

3.3 联合作战案例：全链路存储调优

某金融系统迁移到Ceph集群后出现交易延迟，通过组合测试定位问题：

# 第一阶段：快速排查
dd if=/dev/zero of=/ceph_mount/test bs=4M count=1000 oflag=direct

# 第二阶段：定位IO模式
fio --name=randrw --rw=randrw --bs=4k --iodepth=128 --runtime=600 --filename=/ceph_mount/fio_test

# 第三阶段：元数据瓶颈验证 
bonnie++ -d /ceph_mount -s 20G -n 500:100000:10:120 -m CEPH_TEST

最终发现症结在于Ceph的metadata pool配置了3副本，而默认的filestore参数不适合高频小文件操作。调整到erasure coding+bluestore后，随机读性能提升4倍。

四、避坑指南与进阶技巧

4.1 五个必须检查的"安全阀"

1. 缓存陷阱：始终在命令中添加oflag=direct或--direct=1
2. 容量规划：测试文件大小要超过RAM三倍
3. 权限准备：对docker容器内的挂载点需添加--privileged
4. 散热监控：持续运行iostat -xmt 1观察温度对性能的影响
5. 环境隔离：使用cgroups限制资源干扰

4.2 专家级调优参数表

为不同硬件配置推荐的最佳参数组合：

4.3 性能数据智能分析脚本

将原始结果转换为可视化报告的Shell技巧：

# 处理fio输出的JSON结果
cat result.json | jq '.jobs[] | {"任务":.jobname, "读IOPS":.read.iops, "写IOPS":.write.iops}'

# 生成bonnie++对比表格
bon_csv2html < result.csv > report.html

# 自动提取dd测试均值
dd if=/mnt/test/testfile of=/dev/null bs=1M 2>&1 | awk '/copied/ {sum+=$10} END {print "平均速度:",sum/NR,"MB/s"}'

五、测试兵法总结

存储性能评估本质上是在回答三个问题：

• 最大能跑多快？（dd）
• 持续能扛多久？（fio）
• 综合表现如何？（bonnie++）

通过本文的对比可见：

1. 快速初诊用dd：执行速度最快，适合硬件验收
2. 精准压测用fio：场景定制灵活，适合研发调试
3. 全面体检用bonnie++：覆盖元数据操作，适合架构选型

未来的演进方向已初见端倪：通过eBPF实现动态负载注入、与Prometheus集成实现持续性能监控等新技术正在重塑存储测试的疆界。但无论工具如何进化，把握存储介质的物理特性与业务场景的访问模式，始终是性能优化的不二法门。