深入解析fio：从核心原理到实战的存储性能测试指南

1. 项目概述：为什么存储性能测试是每个工程师的必修课

在数据中心、云平台乃至个人工作站上，存储设备的性能表现直接决定了整个系统的响应速度和稳定性。无论是评估新采购的SSD是否达标，还是排查生产环境数据库为何突然变慢，亦或是验证分布式文件系统的IO能力，我们都需要一把精准的“尺子”来量化存储性能。这把尺子，就是fio。

fio，全称Flexible I/O Tester，是一款功能极其强大且灵活的存储性能基准测试与验证工具。它不像一些图形化工具那样简单易用，但正是这种“不简单”，赋予了它无与伦比的深度和广度。你可以用它模拟出几乎任何你能想象到的I/O负载：从数据库的随机小写，到视频剪辑的顺序大读；从单一线程的简单测试，到成百上千个线程的混合压力场景。很多存储厂商的官方性能数据，背后很可能就是由fio测试得出的。

我接触fio超过十年，从最初在命令行里敲几个简单参数，到后来为超大规模云存储集群设计复杂的测试套件，踩过的坑不计其数。很多新手觉得fio参数繁多、难以掌握，其实一旦理解了其核心设计哲学，它就会成为你手中最得心应手的利器。这篇文章，我将抛开手册式的罗列，从一个资深使用者的角度，带你彻底吃透fio，不仅告诉你每个参数怎么用，更会解释为什么要这么用，以及在实际工程中如何避开那些教科书上不会写的“暗礁”。

2. fio核心设计哲学与工作流程拆解

要驾驭fio，首先要理解它的核心设计。fio不是一个简单的“发IO”工具，而是一个完整的I/O负载模拟与调度框架。

2.1 核心模型：Job、Thread/Process与IO Engine

fio的测试由一个或多个job构成。每个job定义了一种独立的I/O负载模式。你可以在一个测试中同时运行多个job，比如一个job模拟Web服务器的日志写入，另一个job模拟应用读取静态资源，从而复现真实的混合负载。

每个job下，可以启动多个执行线程或进程（通过numjobs参数控制），它们协同完成该job定义的I/O任务。这里的关键在于I/O引擎。I/O引擎决定了fio如何与存储设备“对话”。最常用的是libaio（Linux原生异步I/O），它效率最高，能真正实现异步并发。对于Windows或需要兼容性的场景，可能会用到windowsaio或sync（同步I/O）。选择正确的引擎是获得准确结果的第一步。

注意：使用libaio需要内核和文件系统的支持，并且在测试文件（而非裸设备）时，它绕过了操作系统的页面缓存（Page Cache），直接进行直接I/O，这更能反映存储设备本身的性能，但也意味着你的测试数据必须大于可用内存，否则可能会触发同步写入，影响结果。

2.2 工作流程四阶段

一个fio job的执行，清晰地分为四个阶段，理解这个流程对分析测试结果至关重要：

1. 初始化：根据参数创建测试文件（filename），并将其填充到指定大小（size）。填充内容可以是全零、随机数据或特定模式。这一步确保了后续读写操作是在真实的数据块上进行的，避免了存储设备压缩、去重等优化带来的性能虚高。
2. 预热：可选的rw=randread或rw=randwrite阶段。目的是让存储设备（尤其是SSD）进入稳定状态。SSD在空盘和满盘状态下的性能、特别是写入性能，差异巨大。预热相当于“热身”，让测试结果更接近设备长期运行的真实水平。
3. 运行：执行核心的I/O测试。根据runtime或iodepth、size等限制，持续进行读写操作，并在此阶段收集所有的性能指标（IOPS、带宽、延迟）。
4. 清理：测试结束后，根据设置删除测试文件。

很多初学者直接运行测试，发现结果波动很大，往往是因为忽略了预热阶段。对于任何严肃的性能评估，尤其是针对SSD，必须包含足够时长的预热阶段。

3. 参数精讲：从命令行到配置文件

fio可以通过命令行参数直接运行，但对于复杂的测试，强烈推荐使用配置文件。配置文件更清晰，易于维护和复用。我们先从最核心的参数讲起。

3.1 全局参数与Job参数

fio的参数分为全局参数和job参数。全局参数定义在[global]部分，会被所有job继承。Job参数定义在独立的[job_name]部分，可以覆盖全局设置。

一个经典的配置文件骨架如下：

[global] ioengine=libaio direct=1 thread=1 group_reporting=1 time_based runtime=60 [4k-randread] name=4k_random_read_test rw=randread bs=4k size=10G numjobs=4 iodepth=32 filename=/dev/nvme0n1

3.2 读写模式与块大小：定义负载形态

这是定义测试场景的核心。

• rw：读写模式。这是最重要的参数之一。

  • read/write：顺序读/写。模拟大文件连续访问，如视频流、备份恢复。
  • randread/randwrite：随机读/写。模拟数据库、虚拟机、操作系统启动等场景。
  • rw/randrw：混合读写。需要配合rwmixread或rwmixwrite来指定读写比例（如rwmixread=70表示70%读，30%写）。这是最贴近真实应用的场景。
  • trim：发送TRIM/UNMAP指令，用于测试SSD的垃圾回收性能。

• bs：块大小。它决定了每次I/O操作的数据量。

  • 4k：这是最常见的随机I/O大小，对应操作系统和很多数据库的页大小。
  • 128k或1m：常见于顺序流式读写。
  • 你可以使用bsrange来指定一个范围（如bsrange=4k-64k），fio会在此范围内随机选择块大小，模拟更不规则的负载。

选择依据：测试数据库性能，通常从bs=4k-16k的随机读写开始；测试文件服务器或备份系统，则更关注bs=128k-1m的顺序吞吐。

3.3 队列深度与并发数：施加压力

这两个参数决定了向存储设备施加压力的强度。

• iodepth：I/O队列深度。它控制着每个job线程/进程同时发起的未完成的（in-flight）I/O请求数量。这是压测中最关键的参数之一。单次I/O延迟可能很低，但系统整体的吞吐能力（IOPS/BW）需要通过提高队列深度来挖掘。

  • 对于低延迟的NVMe SSD，可能需要iodepth=32甚至128才能达到标称性能。
  • 对于机械硬盘，过高的队列深度（如>32）可能因寻道时间导致延迟急剧上升，吞吐反而下降。

• numjobs：并发任务数。它创建多个执行相同I/O模式的线程或进程。增加numjobs可以模拟多应用并发访问的场景。

  • iodepthvsnumjobs：iodepth=4, numjobs=8意味着总共有4 * 8 = 32个in-flight I/O请求。但它们的模型不同：iodepth是单个线程的异步深度；numjobs是多个线程的并发。在ioengine=libaio下，通常用较高的iodepth配合适中的numjobs来达到目标压力。而使用同步引擎时，则需要靠增加numjobs来提高并发。

3.4 关键性能指标与输出解读

fio运行结束后，会输出一份详细的报告。看懂这份报告，才算完成了测试。

Run status group 0 (all jobs): READ: bw=125MiB/s (131MB/s), 125MiB/s-125MiB/s (131MB/s-131MB/s), io=8192MiB (8590MB), run=60001-60001msec WRITE: bw=42.3MiB/s (44.3MB/s), 42.3MiB/s-42.3MiB/s (44.3MB/s-44.3MB/s), io=2714MiB (2846MB), run=60001-60001msec

• bw (Bandwidth)：带宽，单位通常是 MiB/s (Mebibytes per second) 或 MB/s。顺序读写性能的主要指标。
• iops：每秒I/O操作数。随机读写性能的主要指标。在报告中，它可能直接显示，也可能需要计算（iops = bw / bs）。
• lat (Latency)：延迟。这是衡量存储响应速度的核心指标，通常关注以下几个百分位数：
  • clat：完成延迟，指I/O请求从发起到完成的时间。
  • slat：提交延迟，指从请求发出到被内核/设备接受的时间。
  • lat：总延迟，lat = slat + clat。
  • 报告中的延迟分布，如lat (usec): min=20, max=12003, avg=105.32, stdev=201.44，以及更重要的百分位延迟percentile (usec)，如99.00th=[ 380]，99.99th=[ 1200]。99.9%或99.99%的尾部延迟，对于数据库等延迟敏感型应用至关重要，平均延迟很低但尾部延迟很高，体验依然会很差。

实操心得：不要只看平均IOPS或带宽。一个平均IOPS 80k的SSD，如果99.99%延迟高达几百毫秒，在生产高峰期可能就是灾难。务必结合延迟分布报告来分析性能。

4. 实战：设计并执行一个完整的性能评估方案

理论说再多，不如动手跑一遍。假设我们要评估一块新上线的NVMe SSD（设备名为/dev/nvme0n1）作为数据库存储的性能。

4.1 测试方案设计

我们的目标是模拟OLTP数据库负载：主要是随机、小块（4K-16K）的读写，读写比例大约7:3。测试需要包含预热，并观察不同队列深度下的性能变化。

我们设计一个三阶段的测试配置文件db_test.fio：

[global] ioengine=libaio direct=1 thread=1 group_reporting=1 time_based runtime=30 filename=/dev/nvme0n1 size=100G # 测试文件大小，建议远超设备缓存 # 阶段一：预热，让SSD进入稳定状态 [precondition] name=precondition_phase rw=randwrite bs=128k iodepth=32 numjobs=1 runtime=300 # 预热5分钟 loops=1 # 阶段二：随机读基准测试 [4k_randread_qd1] stonewall # 确保此job在前一个job完成后才开始 name=4k_random_read_qd1 rw=randread bs=4k iodepth=1 numjobs=1 [4k_randread_qd8] stonewall name=4k_random_read_qd8 rw=randread bs=4k iodepth=8 numjobs=1 [4k_randread_qd32] stonewall name=4k_random_read_qd32 rw=randread bs=4k iodepth=32 numjobs=4 # 提高并发数以产生足够压力 # 阶段三：混合读写测试 [4k_70read_30write_qd32] stonewall name=4k_70r30w_qd32 rw=randrw rwmixread=70 bs=4k iodepth=32 numjobs=4

设计思路解析：

1. 预热：使用顺序大块写入快速填充SSD的空白空间，使其FTL（闪存转换层）和垃圾回收机制进入活跃状态。
2. 队列深度扫描：从低队列深度（iodepth=1）开始测试，这反映了设备在低并发下的最佳延迟。逐步增加队列深度（qd8,qd32），观察IOPS和延迟的变化曲线，找到性能拐点。
3. 混合负载：最后进行最接近真实的混合读写测试。numjobs=4模拟了多个数据库连接并发操作。

4.2 执行与监控

运行测试：

fio db_test.fio --output=db_test_result.log

在测试运行时，不要只盯着最终报告。打开另一个终端，使用系统监控工具观察：

• iostat -xmt 1 /dev/nvme0n1：观察设备的实时利用率（util%）、读写速率、平均请求大小和等待时间（await）。
• pidstat -d 1：查看fio进程的详细I/O情况。
• 对于Linux，还可以用blktrace和blkparse进行更底层的块设备追踪，但这属于高级用法。

监控的目的是确认测试负载确实如预期施加到了目标设备上，并且没有其他系统瓶颈（如CPU跑满、内存不足）干扰测试结果。

5. 高级技巧与避坑指南

掌握了基础，我们来看看那些容易踩坑和能体现功力的地方。

5.1 确保测试准确性：避开系统缓存

这是新手最容易犯的错误，导致测出的性能高得离谱。

• direct=1：这是最重要的开关。它指示fio使用直接I/O，绕过操作系统的页面缓存。几乎所有针对裸设备或文件系统底层性能的测试，都必须加上direct=1。
• buffered=0：与direct=1互斥，使用缓冲I/O。除非你明确想测试文件系统缓存性能，否则不用。
• 测试文件大小：size参数必须远大于系统可用内存。否则，即使用了direct=1，文件系统或设备自身的DRAM缓存也可能扭曲结果。经验法则是size至少是内存的2-3倍。

5.2 理解并控制I/O模式

• random_distribution=random：这是默认的随机分布。对于模拟数据库，这通常是合适的。你还可以选择zipf（齐夫分布，更贴近某些热点数据访问模式）或pareto（帕累托分布）。
• norandommap：当进行随机I/O时，fio默认会维护一个“随机映射”，确保每个逻辑块只被访问一次，直到所有块被访问完。这避免了测试中反复读写同一块区域（热点）。在大多数情况下，不要使用norandommap，除非你明确想测试特定区域的重度访问。
• offset和offset_increment：可以指定测试从设备的某个偏移量开始，或者为每个job设置不同的起始点，用于测试设备不同区域的性能一致性（对于大容量HDD或某些SSD可能有差异）。

5.3 结果分析与呈现

fio的原始输出日志已经很详细，但我们可以做得更好。

• 使用--output-format=json或--output-format=json+输出JSON格式的结果，便于用脚本（Python、jq）进行自动化分析和可视化。
• 将多次测试的关键指标（如不同qd下的IOPS、平均延迟、99.9%延迟）整理成表格或图表，能直观展示性能曲线。
• 重点关注性能一致性。连续运行多次测试，观察结果波动范围。高性能但波动大的存储，不如性能稍低但极其稳定的存储可靠。

5.4 常见问题排查实录

问题1：IOPS远低于预期，且iostat显示util%始终100%。

• 排查：首先检查iostat中的avgqu-sz（平均队列长度）。如果它远小于你设置的iodepth，说明压力没打满。可能瓶颈在CPU（pidstat查看fio进程CPU使用率）或numjobs设置太少。如果avgqu-sz很高，但iops低，await高，则很可能是遇到了设备瓶颈，或者测试模式（如随机写）触发了SSD的垃圾回收，导致性能下降。此时可以尝试延长预热时间或更换测试模式验证。

问题2：测试延迟异常高，且有大量超时错误。

• 排查：查看fio输出中是否有错误信息。检查dmesg系统日志，看是否有设备错误、链路降速或驱动问题。对于网络存储（如iSCSI、NFS），需要排查网络延迟和丢包。降低iodepth和numjobs，看延迟是否恢复正常，以判断是否是过载导致。

问题3：混合读写测试中，读和写的IOPS比例与rwmixread设置不符。

• 解析：这是正常现象。rwmixread控制的是I/O数量的比例，而不是数据量的比例。因为读和写的延迟通常不同，在固定时间内，完成的读写操作数量比例自然会偏离设定值。fio会尽力逼近设定比例，但受设备性能影响。如果需要精确控制数据量比例，需要更复杂的脚本控制。

问题4：在虚拟化环境或容器中测试，结果波动大。

• 建议：虚拟化层引入了额外的调度和模拟开销。尽量在宿主机上对物理设备进行测试以获得基线数据。在虚拟机内测试时，需明确测试目标是“虚拟机看到的存储性能”，需保持宿主机负载稳定，并多次测试取平均值。避免在共享存储上与其他高负载虚拟机同时测试。

掌握fio是一个从“会用”到“精通”的渐进过程。它没有华丽的界面，但每一个参数都对应着存储系统的一个真实特性。最好的学习方式就是结合具体的存储设备和应用场景，不断地设计测试、分析结果、调整参数、对比验证。当你能够用fio精准地复现出一个生产环境的I/O压力模型时，你对存储性能的理解就已经超越了绝大多数人。