1. 磁盘性能测试的底层逻辑与工具选型1.1 为什么磁盘性能测试总在“打架”做存储和运维的人都有一个共同的痛同一块盘用不同工具跑出来的数字能差出好几倍。有人拿fio跑出50万IOPS换vdbench一测只剩20万然后就开始怀疑人生——到底是盘不行还是工具在骗我这个问题的根源在于磁盘性能测试从来不是“跑个分”那么简单。它本质上是在模拟特定业务场景下的IO负载而不同工具对IO行为的建模方式、参数默认值、统计口径都不一样。你测的是4K随机读但队列深度设了1那测出来的就是单线程延迟跟IOPS峰值没有半毛钱关系。我在实际项目中见过太多这样的案例采购了一批NVMe SSD验收时用fio默认参数跑数据漂亮得不行结果上线后数据库该卡还是卡。后来一查业务侧是128K顺序写为主而验收测的是4K随机读——完全测错了方向。所以这篇文章不打算给你一个“哪个工具更好”的简单结论而是把vdbench和fio这两个主流工具拆开揉碎从IO引擎、参数模型、统计方式到实战场景一层层讲清楚它们各自的脾气和适用边界。看完之后你至少能做到拿到一块盘知道该用哪个工具、怎么配参数、怎么看结果而不是被数字牵着鼻子走。1.2 两个工具的出身决定了它们的性格vdbench是Oracle出品的存储性能验证工具最早是为了测试Oracle数据库在各类存储上的表现而开发的。它的基因里带着强烈的“企业级存储验证”色彩——支持多主机并发、文件系统和裸设备、丰富的报告维度而且自带数据校验功能。你可以把它理解成一个“存储验收专家”适合做大规模、长时间、多节点的稳定性验证。fio则是 Jens Axboe 大神开发的IO测试工具这位同时也是Linux内核IO子系统的维护者。fio的设计哲学是“灵活到极致”它几乎能模拟任何你能想到的IO模式从简单的顺序读到复杂的混合随机读写、从单线程到多线程多设备并发。它的参数多到令人发指但也正因为如此fio成了事实上的行业标准——几乎所有存储厂商的规格书里写的IOPS都是用fio跑出来的。打个比方vdbench像是一辆调校好的工程车开箱即用适合拉货跑长途fio像是一套乐高积木什么都能拼但你得知道自己要拼什么。选哪个取决于你的场景和目的。1.3 选型前必须想清楚的三个问题在决定用哪个工具之前先问自己三个问题第一你测的是裸设备还是文件系统裸设备测试绕过了文件系统层测的是块设备的原始性能文件系统测试则包含了元数据操作、缓存、日志等开销。vdbench对两者的支持都很完善fio则需要通过filename参数指定文件路径或设备路径来区分。第二你需要多主机并发吗如果你的存储是共享的SAN或NAS需要验证多客户端同时访问时的性能表现vdbench的多主机编排能力是碾压级的。fio虽然也能多机跑但需要自己写脚本协调麻烦不少。第三你需要数据一致性校验吗vdbench内置了数据校验功能可以在读写过程中验证数据完整性这对存储稳定性验证非常关键。fio也有verify选项但配置起来相对繁琐。这三个问题想清楚了工具选型基本就定了。下面我们进入实战环节。2. fio核心参数拆解与IO引擎深度解析2.1 IO引擎fio的灵魂所在fio最核心的概念就是IO引擎ioengine它决定了fio用什么方式向操作系统提交IO请求。不同的引擎走的内核路径完全不同性能表现也天差地别。选错引擎测出来的数据毫无参考价值。目前最常用的几种引擎引擎名称工作方式适用场景注意事项sync同步IOread/write系统调用单线程低并发场景性能最差仅用于基线对比libaioLinux原生异步IO高并发裸设备/文件测试需要内核支持队列深度才能生效io_uring新一代异步IO接口高并发低延迟场景需要较新内核5.1posixaioPOSIX异步IO跨平台兼容场景Linux上性能不如libaiommap内存映射方式特定缓存测试容易受页缓存影响我个人的经验是在Linux上测块设备性能libaio是默认首选除非内核版本足够新且你想压榨极致性能那就上io_uring。sync引擎只在你想知道“最差情况”时才有用。这里有个坑要特别注意libaio的队列深度iodepth必须大于1才能真正发挥异步优势。如果你设了ioenginelibaio但iodepth1那它实际上退化成了同步IO性能数据会非常难看。我见过不止一个人踩这个坑然后得出“这块盘不行”的错误结论。2.2 那些你必须搞懂的fio参数fio的参数有上百个但真正影响测试结果的核心参数就那么十几个。我把它们分成四类来讲IO模式类rw读写模式可选read、write、randread、randwrite、randrw、readwrite等。这是最基础的参数决定了IO的方向和随机性。bs块大小支持4k、8k、64k、1m等单位。块大小直接决定了IOPS和带宽的换算关系。rwmixread混合读写时的读比例比如rwrandrw配合rwmixread70表示70%读30%写。并发类iodepth队列深度即同时提交的IO请求数。这是影响IOPS最关键的参数之一。numjobs并发线程数或进程数。每个job独立运行可以理解为模拟多少个客户端。thread让numjobs以线程而非进程方式运行减少上下文切换开销。目标类filename测试目标可以是设备路径如/dev/nvme0n1或文件路径。size每个job的IO总量影响测试持续时间。runtime测试运行时间配合time_based使用。direct是否绕过页缓存1表示直接IO0表示走缓存。测真实磁盘性能必须设direct1。输出类output结果输出到文件。output-format输出格式可选normal、json、json、terse等。json格式方便后续用脚本解析。一个典型的4K随机读测试命令长这样fio --namerandread --ioenginelibaio --direct1 \ --bs4k --rwrandread --iodepth32 --numjobs4 \ --filename/dev/nvme0n1 --size10G --runtime60 \ --time_based --group_reporting --output-formatjson \ --outputresult.json这条命令的意思是用libaio引擎直接IO4K随机读队列深度324个并发job总共等效队列深度128跑60秒结果输出为JSON。2.3 队列深度与IOPS的数学关系很多人搞不清楚iodepth和numjobs的关系。简单说总队列深度 iodepth × numjobs。但这里有个前提——只有异步引擎才能让iodepth真正生效。IOPS的理论上限可以用一个公式估算IOPS 总队列深度 / 平均延迟比如你的盘平均延迟是100微秒总队列深度128那理论IOPS 128 / 0.0001 1,280,000。当然这是理想值实际受限于设备控制器、总线带宽等因素。反过来如果你知道盘的标称IOPS和延迟也可以反推需要多大的队列深度才能跑满所需队列深度 IOPS × 延迟假设盘标称500K IOPS延迟80微秒那所需队列深度 500000 × 0.00008 40。也就是说iodepth至少要到40才能跑出标称性能。这个计算在实际调参时非常有用。我经常用它来快速判断当前测出来的IOPS偏低到底是盘的问题还是队列深度不够。2.4 一个容易被忽略的细节数据布局fio默认会在测试文件或设备上顺序写入数据但如果你反复测试同一块盘之前的数据布局会影响后续测试结果。特别是对SSD来说FTL闪存转换层的映射表状态会直接影响写入性能。我的做法是每次测试前先用blkdiscard对SSD或写零操作把盘恢复到干净状态。对于机械盘至少也要保证测试区域是连续的。这个步骤看起来不起眼但能让你的测试结果可复现性大幅提升。另外size参数不要设得比实际可用空间还大否则fio会报错。一般建议设为设备容量的50%-80%留出足够的空间给FTL做垃圾回收。3. vdbench实战从单机验证到多机并发3.1 vdbench的工作模型vdbench的使用方式和fio截然不同。它不是通过命令行参数直接定义负载而是通过一个参数文件parameter file来描述整个测试场景。这个文件里定义了SDStorage Definition、WDWorkload Definition、RDRun Definition三个核心部分。SD定义存储目标可以是裸设备、文件系统路径、或网络共享。WD定义工作负载包括IO模式、块大小、读写比例、线程数等。RD定义运行规则包括运行时间、预热时间、多主机配置等。这种分层设计的好处是清晰、可复用。你可以把SD和WD分开维护不同的RD组合出不同的测试场景。一个最简单的vdbench参数文件sdsd1, lun/dev/nvme0n1, threads8 wdwd1, sdsd1, rdpct100, seekpct100, xfersize4k rdrd1, wdwd1, ioratemax, elapsed60, interval1这段配置的意思是定义一个名为sd1的存储目标8个线程工作负载wd1是100%随机读4K块大小运行60秒每秒报告一次。3.2 vdbench的独门绝技数据校验vdbench最让我放心的一点是它的数据校验功能。在参数文件中加上validateyes它会在写入数据时生成校验信息读取时验证数据是否一致。这对于验证存储系统的可靠性非常关键。我经历过一次存储控制器固件bug导致的数据静默损坏就是用vdbench的校验功能发现的。当时fio跑了几小时都没报错但vdbench一跑就报数据不匹配。后来厂商确认是固件问题更新后解决。如果没有vdbench的校验这种问题可能要等到业务数据出错才会被发现。配置校验的写法wdwd1, sdsd1, rdpct50, whpct50, xfersize4k, seekpct100, validateyes注意开启校验后性能会有所下降因为多了校验信息的读写开销。所以做纯性能测试时可以关掉做稳定性验证时再打开。3.3 多主机并发测试的配置方法vdbench的多主机能力是它区别于fio的最大优势。配置方式是在参数文件中指定多个主机每个主机上运行vdbench的从进程slave由主进程统一调度。主参数文件hddefault, vdbenchvdbench, userroot, shellssh hdhost1, system192.168.1.101 hdhost2, system192.168.1.102 hdhost3, system192.168.1.103 sdsd1, lun/dev/nvme0n1, threads8, hosthost1 sdsd2, lun/dev/nvme0n1, threads8, hosthost2 sdsd3, lun/dev/nvme0n1, threads8, hosthost3 wdwd1, sdsd1,sd2,sd3, rdpct100, seekpct100, xfersize4k rdrd1, wdwd1, ioratemax, elapsed300, interval5这个配置会在三台主机上同时发起4K随机读vdbench会自动汇总所有主机的性能数据。注意hd定义中的shellssh表示通过SSH连接从机需要提前配置好免密登录。多机测试时有个关键点确保所有主机的时钟同步。否则汇总报告的时间戳会对不齐影响分析。我一般会提前用NTP把所有节点的时间校准一遍。3.4 vdbench报告解读要点vdbench的输出报告非常详细但信息量大也意味着容易看花眼。我一般重点关注这几个指标rate每秒完成的IO次数即IOPS。resp平均响应时间单位毫秒。cpu各主机的CPU占用率。MB/sec吞吐量。报告会按时间间隔interval逐行输出最后给出汇总。看报告时要注意区分“总速率”和“单主机速率”。在多机测试中总速率是所有主机之和但单主机的表现可能差异很大。如果某台主机的速率明显偏低可能是网络瓶颈或配置不一致导致的。另外vdbench的响应时间统计包含了队列等待时间所以高队列深度下响应时间会自然升高。不要看到响应时间从0.1ms涨到2ms就慌了先看看队列深度是多少。4. 实战对比同一块盘两个工具跑出不同结果怎么办4.1 对比测试的设计原则要公平对比vdbench和fio必须保证测试条件一致。我总结了几个必须对齐的维度对比维度fio参数vdbench参数说明块大小bs4kxfersize4k必须一致读写比例rwrandreadrdpct100,seekpct100随机读队列深度iodepth×numjobsthreads等效并发数直接IOdirect1openflagso_direct绕过缓存运行时间runtime60elapsed60相同预热无内置可设warmupvdbench更优我一般会先用fio跑一轮记录IOPS、带宽、延迟然后用vdbench跑相同条件的测试对比结果。如果差异在5%以内说明两个工具的一致性很好如果差异超过10%就需要排查原因了。4.2 差异来源排查清单实测中两个工具跑出不同结果是常态差异来源主要有以下几个第一队列深度的计算方式不同。fio的总队列深度是iodepth×numjobs但vdbench的threads是每个SD的线程数实际并发可能受限于iorate参数。如果ioratemaxvdbench会尽可能快地提交IO但具体并发数取决于线程调度。第二统计口径不同。fio的IOPS统计包含了所有完成的IO而vdbench可能会排除某些异常值。另外fio的延迟统计默认包含队列等待时间vdbench的resp也是。第三数据布局影响。如果两次测试之间没有清理盘之前的数据分布会影响FTL状态导致性能差异。这个在SSD上尤其明显。第四CPU亲和性。fio可以通过cpus_allowed绑定CPUvdbench没有这个功能。在高IOPS场景下CPU调度可能成为瓶颈。我的建议是不要纠结于两个工具的数字是否完全一致而是关注它们在同一条件下的相对表现。比如你要对比两块盘的性能那就用同一个工具、同一套参数去测这样才有可比性。4.3 一个真实的对比案例去年我帮一个客户验收一批企业级NVMe SSD标称4K随机读IOPS 800K。我先用fio跑fio --nametest --ioenginelibaio --direct1 --bs4k \ --rwrandread --iodepth64 --numjobs8 --filename/dev/nvme0n1 \ --size50G --runtime120 --time_based --group_reporting结果IOPS约620K延迟约0.82ms。然后用vdbench跑等效配置sdsd1, lun/dev/nvme0n1, threads512, openflagso_direct wdwd1, sdsd1, rdpct100, seekpct100, xfersize4k rdrd1, wdwd1, ioratemax, elapsed120, interval5, warmup30结果IOPS约680K延迟约0.75ms。差异约9%。排查后发现两个原因一是vdbench有30秒预热盘进入了更稳定的状态二是fio的numjobs8产生了额外的进程调度开销。后来我把fio改成numjobs1, iodepth512IOPS提升到了670K差距缩小到1.5%。这个案例说明参数配置的细微差异会导致结果显著不同对比测试时必须严格控制变量。5. 常见问题与排查技巧实录5.1 fio测试结果异常排查问题一IOPS远低于预期。排查顺序先确认direct1是否设置如果走了页缓存测的是内存速度而非磁盘速度再检查iodepth是否足够大用前面讲的公式估算所需队列深度然后确认ioengine是否选对sync引擎在高并发下会成为瓶颈最后检查CPU占用率如果某个核跑满了说明CPU是瓶颈。问题二延迟波动很大。可能原因包括后台有其他进程在抢IO、SSD正在做垃圾回收、测试文件碎片化严重。解决方法测试前清理盘、关闭不必要的后台服务、用blkdiscard重置SSD状态。问题三读写混合测试时结果不稳定。检查rwmixread是否设置合理以及randrw模式下读写是否真的随机分布。有时候fio的随机数生成器会成为瓶颈可以尝试randrepeat0让每次运行的随机序列不同。5.2 vdbench常见报错与解决报错一Cannot open /dev/xxx。通常是权限问题。vdbench需要root权限才能直接访问块设备。确认用root运行或者检查设备文件的权限。报错二多机测试时从机连接失败。检查SSH免密登录是否配置正确防火墙是否放行了vdbench使用的端口默认5570。另外确认所有主机上的vdbench版本一致版本不一致可能导致协议不兼容。报错三数据校验失败。如果开启了validateyes且报数据不匹配首先排除是测试配置问题比如多个job写同一区域。如果配置没问题那很可能是存储系统的问题建议联系厂商排查。5.3 工具选择的经验法则跑了这么多年测试我总结了一个简单的选择逻辑快速验证、参数调优、厂商规格对比→ 用fio。灵活、快、行业标准。存储验收、稳定性验证、多机并发→ 用vdbench。全面、可靠、报告清晰。两者都用→ 重要项目建议两个工具交叉验证结果一致才放心。注意无论用哪个工具测试前一定要备份数据。直接IO操作会覆盖设备上的原有数据且不可恢复。5.4 性能测试的“三不原则”最后分享三条我在实践中总结的原则不测无预热的数据。任何存储设备在冷启动和热稳定状态下的性能都不一样。至少预热30秒等性能曲线平稳后再取数据。不只看峰值。峰值IOPS好看但不代表实际体验好。关注P99延迟、性能一致性IOPS波动范围这些更能反映真实体验的指标。不忽略环境差异。同样的盘插在不同服务器上、走不同的PCIe通道、配不同的BIOS设置性能都可能不同。测试报告里一定要记录完整的硬件和软件环境信息。这三条看起来简单但真正做到的人不多。我见过太多测试报告只写了一个IOPS数字没有任何上下文这种数据拿来做决策是很危险的。实际项目中我通常会跑三轮测试第一轮摸底找到大致性能范围第二轮调参优化队列深度和并发数第三轮验证用最优参数跑长时间稳定性测试。三轮下来对这块盘的脾气就摸得差不多了。这个过程比单纯跑一个命令要费时间但得到的结论可靠得多。
