深度解析vdbench与fio：磁盘性能测试的实战指南-编程阁

1. 为什么需要专业的磁盘性能测试工具

当你新买了一块硬盘，或者搭建了一个存储系统，最想知道的是什么？当然是它的性能到底如何。就像买车要试驾一样，磁盘也需要"试驾"工具。我在实际工作中见过太多人用简单的文件拷贝来测试磁盘速度，结果被缓存机制坑得怀疑人生。真正的性能测试需要模拟真实业务场景，这就是为什么我们需要vdbench和fio这样的专业工具。

这两个工具最大的特点是能够精确控制测试条件。比如你可以设置顺序读写还是随机读写，调整队列深度，模拟多线程并发访问，甚至混合读写比例。这些参数对应着不同的业务场景：数据库喜欢小块的随机读写，视频处理需要大块的顺序读写，而云存储往往需要混合负载。

我曾经帮一个客户调试NAS性能问题，他们用常规方法测试显示速度很快，但实际业务中却频繁卡顿。后来用fio设置了32线程随机读写，才发现磁盘的IOPS根本达不到标称值。这就是专业工具的价值——它能暴露真实场景中的性能瓶颈。

2. vdbench从入门到精通

2.1 环境搭建与快速上手

vdbench是Oracle开发的存储性能测试工具，用Java编写所以跨平台性很好。安装其实特别简单，我习惯用下面这个一键脚本：

# 安装JDK yum install java-1.8.0-openjdk -y # 下载vdbench wget https://download.oracle.com/otn/utilities_drivers/vdbench/vdbench50407.zip unzip vdbench50407.zip cd vdbench50407 chmod +x vdbench

第一次使用时建议创建一个测试目录作为基准点，比如我在/root/vdbench_test下放了三个配置文件：

basic_read.conf：基础读测试
basic_write.conf：基础写测试
mixed.conf：混合读写测试

最简单的读测试配置长这样：

fsd=fsd1,anchor=/mnt/test,depth=1,width=1,files=10,size=1G fwd=fwd1,fsd=fsd1,xfersize=4k,operation=read,threads=1 rd=rd1,fwd=fwd1,fwdrate=max,elapsed=60

这个配置会在/mnt/test下创建10个1G文件，然后用单线程进行4k随机读测试，持续60秒。

2.2 高级配置技巧

真正体现vdbench威力的是它的丰富参数。去年我们测试全闪存阵列时，就用到了这些进阶配置：

多级目录结构：

fsd=fsd1,anchor=/mnt/deep,depth=3,width=10,files=5,size=100M

这会创建10^3×5=5000个文件，模拟海量小文件场景。

混合负载模拟：

fwd=fwd1,fsd=fsd1,xfersize=8k,operation=read,threads=8 fwd=fwd2,fsd=fsd1,xfersize=64k,operation=write,threads=4 rd=rd1,fwd=fwd1,fwdrate=100,elapsed=300 rd=rd2,fwd=fwd2,fwdrate=50,elapsed=300

这个配置同时运行8个读线程和4个写线程，读操作每秒100次，写操作每秒50次。

实际案例：某次测试中，我们发现当队列深度增加到32时，机械硬盘的延迟从15ms飙升到200ms。这就是典型的队列堆积现象，说明磁盘已经达到性能极限。

3. fio的灵活应用

3.1 基础测试场景

fio的灵活性在于它支持多种使用方式。最简单的命令行模式适合快速测试：

fio -name=test -filename=/dev/sdb -rw=randread -bs=4k -numjobs=16 -runtime=60

但更推荐使用配置文件方式，特别是需要复杂测试时。这是我常用的模板：

[global] ioengine=libaio direct=1 runtime=300 time_based [4k-randread] rw=randread bs=4k iodepth=32 numjobs=8 filename=/dev/nvme0n1

这个配置会测试NVMe SSD的4k随机读性能，使用8个线程，每个线程队列深度32。

3.2 企业级测试方案

在生产环境中，我通常会设计多阶段测试：

预条件阶段：用write模式填充整个磁盘，避免空闲空间影响
稳态测试：持续运行足够长时间（至少30分钟）
峰值测试：短时间高压力测试
恢复测试：观察压力解除后的性能恢复情况

一个典型的全盘测试配置：

[fill] rw=write bs=1M size=100% filename=/dev/sdb [steady] rw=randrw rwmixread=70 bs=8k iodepth=64 numjobs=16 runtime=1800 filename=/dev/sdb

4. 测试结果分析指南

4.1 关键指标解读

拿到测试结果后，要重点关注这些指标：

带宽（BW）：单位MB/s，适合大块顺序读写
IOPS：每秒IO次数，对小块随机访问更重要
延迟（lat）：特别是第99百分位延迟（lat_99th）

我曾经遇到过一个案例：平均延迟很好（2ms），但第99百分位延迟高达200ms，导致应用时不时卡顿。这就是为什么不能只看平均值。

4.2 常见性能问题

通过测试数据可以诊断很多问题：

带宽不达标：检查是否达到接口速率上限（比如SATA3的600MB/s）
IOPS偏低：可能是队列深度不够或并发不足
延迟波动大：可能是后端存储遇到瓶颈

一个实用的技巧是配合监控工具观察测试时的系统状态：

# 监控磁盘队列 iostat -x 1 # 查看CPU利用率 mpstat 1 # 观察内存使用 vmstat 1

5. 实战经验分享

5.1 测试环境搭建要点

很多人忽略了一个重要事实：测试环境本身会影响结果。我建议：

尽量在裸设备上测试，避免文件系统开销
如果必须用文件系统，测试前先执行sync; echo 3 > /proc/sys/vm/drop_caches
关闭不必要的后台进程和服务
记录完整的系统配置（CPU、内存、驱动版本等）

5.2 避坑指南

这些年我踩过的坑包括：

忘记设置direct=1，结果测的是内存缓存速度
测试时间太短，没有达到稳态
没有预热SSD（新SSD需要先写入一定数据才能达到最佳性能）
忽略温度对性能的影响（高温会导致SSD降速）

有一次测试NVMe SSD时，连续跑了几轮测试后性能突然下降。后来发现是温度超过80度触发了保护机制。现在我都会在测试时用sensors命令监控温度。

6. 进阶技巧：自动化测试方案

对于需要频繁测试的场景，我开发了一套自动化脚本：

自动生成测试配置
并行执行多组测试
收集结果并生成可视化报告
与历史数据对比分析

一个简单的自动化示例：

for bs in 4k 8k 64k 1M; do for rw in read write randread randwrite; do fio --output-format=json --output=${rw}_${bs}.json \ --rw=$rw --bs=$bs --runtime=60 ... done done

这套系统帮助我们发现了多个性能退化问题，比如某次内核更新导致的小文件写入性能下降30%。