fio 磁盘I/O测试工具：从安装到实战性能调优

1. 为什么你需要一个靠谱的磁盘性能“体检医生”如果你刚接手一台服务器或者自己攒了一台NAS第一件事你会做什么装系统配服务我的习惯是先给磁盘做个全面的“体检”。为什么因为磁盘是整个系统的“地基”它的性能好坏直接决定了你后续所有应用的体验上限。想象一下你花大价钱买了块宣称读写速度飞快的NVMe固态硬盘结果数据库跑起来还是慢如蜗牛问题出在哪是配置不对还是硬盘本身有“暗病”这时候你就需要一个像fio这样专业、精准的磁盘I/O测试工具。fio全称Flexible I/O Tester在Linux圈子里是公认的磁盘性能测试“神器”。它不像一些图形化工具那样简单给个分数而是能让你像外科手术一样精准地剖析磁盘在各种压力下的真实表现顺序读写能跑多快随机读写能扛住多少并发延迟的分布情况如何这些数据对于系统调优、硬件选型、甚至是排查一些诡异的性能抖动问题都至关重要。我自己在运维和架构评估中用了它快十年从传统的机械硬盘到最新的PCIe 5.0 SSDfio给出的数据从来没让我失望过。很多人觉得性能测试是运维或资深开发的事其实不然。比如你是个后端开发写的服务突然在高峰期响应变慢你怀疑是数据库磁盘IO瓶颈但怎么证明又或者你是个视频剪辑师想知道新买的移动固态硬盘能不能流畅剪辑4K RAW素材这些场景fio都能给你量化的答案。它就像一个万能压力测试仪你可以自定义“考题”测试模式、块大小、队列深度等然后看你的磁盘“考生”能得多少分。接下来我就带你从零开始玩转fio不仅会用它还要看懂它最后能用它来真正优化你的系统。2. 手把手搞定fio的安装与配置拿到一个工具第一步当然是把它装到系统里。fio的安装方式很灵活你可以通过系统自带的包管理器快速安装也可以从源码编译获取最新特性。我一般推荐新手先用包管理器省事如果你需要特定的版本或进行二次开发再选择源码编译。2.1 最省心的安装方法使用包管理器对于大多数主流Linux发行版直接用包管理器安装是最快的。这能确保安装的版本与系统兼容并且自动处理好依赖关系。在CentOS/RHEL/Fedora等基于RPM的系统上 你可以直接使用yum或dnf。我实测在CentOS 7.9上默认仓库的fio版本可能稍旧但功能完全够用。sudo yum install -y fio或者用dnf新版本系统sudo dnf install -y fio在Ubuntu/Debian等基于APT的系统上 命令同样简单sudo apt update sudo apt install -y fio安装完成后在终端输入fio --version如果能看到版本号输出比如fio-3.xx那就恭喜你安装成功了。这种方式安装的fio开箱即用特别适合快速验证和测试。2.2 追求最新版或自定义编译源码安装指南有时候你可能需要某个特定版本或者想启用一些实验性功能这时候就需要从源码编译。别怕过程其实很标准。以官网发布的fio-2.1.10.tar.gz为例请注意版本会更新请以官网最新为准。首先我们需要一些编译工具和依赖库。不同的系统需要安装的包略有不同。对于CentOS/RHEL系统sudo yum groupinstall -y Development Tools sudo yum install -y libaio-devel对于Ubuntu/Debian系统sudo apt update sudo apt install -y build-essential sudo apt install -y libaio-dev这里安装的libaio-devel或libaio-dev是异步I/O库的开发包对于fio使用高效的libaio引擎至关重要。准备好环境后就可以开始编译安装了# 1. 下载源码包这里以2.1.10为例你也可以去官网找最新版 wget https://brick.kernel.dk/snaps/fio-2.1.10.tar.gz # 2. 解压到指定目录 tar -xzvf fio-2.1.10.tar.gz -C /usr/local/src/ # 3. 进入源码目录 cd /usr/local/src/fio-2.1.10 # 4. 配置编译选项。这一步会检查系统环境并生成Makefile。 # 如果你想安装到自定义目录可以加上 --prefix/your/path ./configure # 5. 编译。这里的 -j 4 表示用4个CPU核心并行编译能大大加快速度。 # 你可以根据自己CPU的核心数调整这个数字。 make -j 4 # 6. 安装到系统 sudo make install安装完成后默认的fio命令会指向/usr/local/bin/fio。你可以再次用fio --version确认版本。源码安装的好处是版本可控而且编译时可以根据需要调整选项。比如你可以通过./configure --help查看所有可选项例如禁用图形支持 (--disable-gfio) 等。3. 读懂fio的“语言”核心参数全解析装好fio打开命令行面对一长串参数是不是有点懵别急fio的参数虽然多但都是有规律的。我们可以把它们分成几大类测试目标、I/O模式、性能指标和结果输出。理解这些参数是你设计出有效测试用例的关键。3.1 定义测试目标和模式这部分参数告诉fio你要测什么文件还是磁盘以及怎么测读还是写顺序还是随机。-filename或-filename: 这是测试的“靶子”。你可以指定一个具体的文件路径如/data/test.bin也可以直接指定一块裸盘如/dev/nvme0n1。这里有个非常重要的坑我踩过如果你指定的是整块磁盘比如/dev/sdafio会直接读写磁盘这会破坏磁盘上现有的所有分区和数据所以在生产环境或存有数据的盘上测试务必指定一个文件路径或者使用临时文件。如果你想测试多个磁盘的并发能力可以用冒号分隔比如-filename/dev/sdb:/dev/sdc。-rw: 这是测试的“招式”。它决定了I/O的模式。read/write: 纯粹的顺序读或顺序写。这是测试磁盘最大连续吞吐量的经典模式比如测硬盘的拷贝大文件速度。randread/randwrite: 纯粹的随机读或随机写。这是测试磁盘IOPS每秒读写操作数的关键模式特别能反映数据库、虚拟机等应用的磁盘性能。rw/randrw: 混合读写。rw是顺序混合randrw是随机混合。对于模拟真实业务场景如在线交易系统非常有用。-bs(block size): I/O的“块大小”。单位可以是k千字节、m兆字节等比如-bs4k、-bs1m。这个参数对性能结果影响巨大。小块如4k更能考验磁盘的随机处理能力IOPS因为每次操作的数据量小但次数频繁大块如1m则更容易跑出高的吞吐量带宽单位MB/s因为每次搬运的数据多。数据库应用通常更关注4k/8k随机性能而视频处理则更关注大块顺序读写性能。-size: 测试文件的“总工程量”。例如-size10G表示总共会对目标文件进行10GB数据的I/O操作。测试总数据量要足够大以避免被操作系统缓存影响结果。对于高速SSD我建议至少设置几十GB让测试能持续跑上一段时间这样结果更稳定。-runtime: 测试的“持续时间”。单位是秒比如-runtime300表示测试跑300秒5分钟。它和-size是互斥的哪个条件先达到测试就停止。我通常更习惯用-runtime因为时间可控方便比较不同配置下的性能。3.2 控制测试的并发与深度现代磁盘尤其是SSD都有很强的并行处理能力。如何让磁盘“忙”起来压榨出它的全部潜力就看这几个参数。-numjobs: 启动多少个“工人”线程或进程来并发执行I/O任务。比如-numjobs16就是模拟16个客户端同时在访问磁盘。增加numjobs通常能提升总的IOPS和带宽直到达到磁盘或系统的瓶颈。-iodepth: 这是队列深度是性能测试中最关键、也最容易误解的参数之一。它指的是每个“工人”job同时向操作系统提交的、尚未完成的I/O请求数量。注意是每个job不是总数。总并发I/O数 ≈numjobs*iodepth。-iodepth1: 表示每个job一次只提交1个I/O请求等这个请求完成了再提交下一个。这是最保守的模式延迟最低但无法发挥磁盘的并发能力。-iodepth32: 每个job会保持最多32个I/O请求在排队。这能更好地压满高性能SSD的内部并行通道从而获得更高的吞吐量但平均延迟可能会上升。 对于SATA SSDiodepth在32左右通常能触及天花板而对于高端的NVMe SSD可能需要128甚至256才能完全发挥其性能。调整这个参数是性能调优的核心步骤之一。-ioengine: I/O引擎即fio与系统交互的底层方式。常用的有libaio: Linux原生的异步I/O引擎效率非常高是测试的首选特别是当iodepth 1 时。使用它需要系统安装libaio库我们之前编译依赖已安装。psync: 基本的同步pread/pwrite简单稳定但并发能力弱适合iodepth1的场景。sync: 最基本的同步读写。 在大多数性能测试中我都会使用-ioenginelibaio。3.3 影响测试真实性的关键开关为了让测试结果更贴近磁盘的真实性能避免被系统缓存“掺水”我们需要打开几个重要的开关。-direct1:这是最重要的一个参数它告诉fio使用直接I/O绕过操作系统的页面缓存Page Cache。如果不设置这个参数你的读写操作可能会先在内存中完成测试结果反映的是内存速度而不是磁盘速度这就失去了测试的意义。所以务必加上-direct1。-group_reporting: 当你有多个jobnumjobs1时这个参数会让fio将所有job的结果汇总后输出一个整体的报告而不是每个job单独输出一大堆信息这样看起来更清晰。-time_based: 如果设置了-runtime但所有job在时间到达前就完成了-size指定的数据量测试会提前结束。加上-time_based后即使-size的任务完成了fio也会继续重复I/O操作直到运行时间达到-runtime的要求。这保证了测试能持续施加压力满指定的时间。4. 设计你的第一次实战测试了解了核心参数我们就能像搭积木一样组合出针对不同场景的测试命令。纸上得来终觉浅我们直接上手跑几个最典型的测试案例。4.1 案例一测量SSD的极限顺序读写带宽假设你新买了一块NVMe SSD想看看它的连续读写速度到底有没有达到宣传的数值。我们可以设计一个顺序读写测试。测试目标测量/dev/nvme0n1这块盘的最大顺序读写带宽。设计思路使用大块1MB、高队列深度、多线程进行纯顺序读写绕过缓存持续30秒。# 测试顺序读 (Sequential Read) fio -filename/dev/nvme0n1 -direct1 -iodepth32 -rwread -bs1m -size100G -numjobs4 -runtime30 -group_reporting -nameseq_read_test # 测试顺序写 (Sequential Write) fio -filename/dev/nvme0n1 -direct1 -iodepth32 -rwwrite -bs1m -size100G -numjobs4 -runtime30 -group_reporting -nameseq_write_test参数解读-filename/dev/nvme0n1: 直接测试整块NVMe盘。警告这会擦除数据请确保这是你要测试的空盘或者用文件路径代替。-iodepth32和-numjobs4: 组合起来产生 32*4128 个并发I/O请求充分压榨NVMe盘的并行能力。-bs1m: 1MB的大块适合测带宽。-size100G-runtime30: 以100GB为总量但最多跑30秒。通常30秒足够让性能稳定。-name: 给测试任务起个名字方便在输出结果里识别。结果怎么看运行后在输出结果中找到类似READ: bw3400MiB/s或WRITE: bw2800MiB/s这样的行。bw就是带宽单位可能是 KiB/s, MiB/s, GiB/s。将其与厂商标称值对比注意单位换算厂商常用MB/s而fio输出是MiB/s1MiB≈1.049MB。4.2 案例二探究数据库的随机读写IOPS数据库操作如MySQL的InnoDB大量涉及小数据块的随机读写。这个测试能告诉你你的磁盘能否支撑高并发的数据库查询。测试目标测量磁盘的4KB随机读写IOPS。设计思路使用小块4KB、高队列深度、多线程进行纯随机读写测试时间60秒。# 测试4KB随机读 (Random Read) fio -filename/data/testfile -direct1 -iodepth64 -rwrandread -bs4k -size50G -numjobs8 -runtime60 -group_reporting -namerandread_4k_test # 测试4KB随机写 (Random Write) fio -filename/data/testfile -direct1 -iodepth64 -rwrandwrite -bs4k -size50G -numjobs8 -runtime60 -group_reporting -namerandwrite_4k_test参数解读-filename/data/testfile: 这次我们指定一个文件路径更安全。确保/data目录所在的分区就是你想要测试的磁盘。-iodepth64和-numjobs8: 并发请求数更高达到512个这对高端SSD是必要的压力。-bs4k: 经典的数据库页大小。-runtime60: 跑一分钟取稳定值。结果怎么看关注输出中的iops值例如read: IOPS185k。这个数字就是每秒的读写操作数。对于SATA SSD随机读IOPS可能在80k-100k左右而好的NVMe SSD可以达到几百k甚至上百万。这个值直接关系到数据库能处理多少并发事务。4.3 案例三模拟真实混合负载真实的服务器负载很少是纯粹的读或写通常是混合的。比如一个Web应用可能有70%的读请求和30%的写请求。fio可以很好地模拟这种场景。测试目标模拟一个读多写少的混合负载70%读30%写观察磁盘在复杂场景下的表现。设计思路使用随机混合读写模式并通过参数控制读写比例。fio -filename/data/testfile -direct1 -iodepth32 -rwrandrw -rwmixread70 -bs4k -size100G -numjobs4 -runtime120 -group_reporting -namemixed_70read_30write新参数解读-rwrandrw: 随机混合读写模式。-rwmixread70: 指定在混合读写中读操作所占的比例为70%那么写操作自然就占30%。这个测试的结果会同时输出读和写的IOPS、带宽和延迟。你需要综合评估在混合压力下读性能是否还能保持较高水平写延迟是否飙升这比单纯的读写测试更有参考价值。5. 像专家一样解读fio测试报告跑完测试终端里刷出一大屏数据别慌。我们挑最重要的几部分来看它们分别讲述了磁盘性能故事的不同章节。第一部分性能摘要这是最直观的结果。以一次随机读测试为例READ: bw215MiB/s (225MB/s), 215MiB/s-215MiB/s (225MB/s-225MB/s), io12.6GiB (13.5GB), run60001-60001msecbw:带宽。这是吞吐量指标表示平均每秒传输了多少数据。215MiB/s是二进制单位括号里的225MB/s是十进制单位。顺序读写测试主要看这个。iops:每秒I/O操作数。在随机读写测试中这是核心指标。它可能单独成行显示如iops55.0k。io: 在测试期间总共完成了多少数据量的I/O。run: 所有线程总的运行时间。第二部分延迟分布这是诊断性能问题的金钥匙lat (usec): min101, max18463, avg1158.32, stdev910.45 clat percentiles (usec): | 1.00th[ 292], 5.00th[ 428], 10.00th[ 524], 20.00th[ 668], | 30.00th[ 796], 40.00th[ 924], 50.00th[ 1064], 60.00th[ 1224], | 70.00th[ 1448], 80.00th[ 1800], 90.00th[ 2608], 95.00th[ 3472], | 99.00th[ 5792], 99.50th[ 7136], 99.90th[11264], 99.95th[12928], | 99.99th[17024]lat/clat:延迟。lat是总延迟从fio提交I/O到完成clat是完成延迟从设备收到I/O到完成。我们更关心clat。单位是微秒usec。min,max,avg: 最小、最大、平均延迟。平均延迟仅供参考它很容易被少数极端值拉高。stdev: 标准差。反映延迟的波动情况。值越大说明延迟越不稳定性能抖动越厉害。百分位延迟clat percentiles:这是最重要的部分它告诉你延迟的分布。例如50.00th[ 1064]: 50%的I/O请求延迟在1064微秒约1毫秒以内。这就是中位数延迟比平均延迟更有代表性。99.00th[ 5792]: 99%的请求延迟在5.8毫秒以内。这意味着只有1%的请求延迟高于此值。99.99th[17024]: 99.99%的请求延迟在17毫秒以内。为什么百分位延迟如此重要想象一下一个数据库平均响应时间1毫秒但99.9%的请求是1毫秒却有0.1%的请求卡顿到100毫秒。对于用户来说体验就是偶尔会“卡一下”。这种“长尾延迟”对用户体验伤害极大。通过fio的百分位报告你可以精准地发现磁盘是否存在这种问题。一个健康的磁盘其99.9%甚至99.99%的延迟都应该在一个可接受的、与中位数相差不大的范围内。第三部分系统资源消耗cpu : usr4.23%, sys24.56%, ctx1234567, majf0, minf45usr/sys: fio进程在用户态和内核态消耗的CPU百分比。如果sys很高说明大量的CPU时间花在了处理I/O的系统调用上。ctx: 上下文切换次数。如果这个数字异常高可能意味着numjobs设置太多导致了不必要的进程调度开销。6. 从测试到调优解决实际性能瓶颈跑分不是目的解决问题才是。当你发现测试结果不理想时如何定位和调优场景一顺序读写带宽远低于预期可能原因1瓶颈不在磁盘而在其他地方。检查测试命令是否加了-direct1如果没有数据可能只在内存取测的是内存速度。检查-bs是否太小测顺序带宽建议用1m或更大块。检查-iodepth和-numjobs是否太小对于NVMe盘尝试将iodepth提高到128或256numjobs提高到8或16。可能原因2PCIe通道或CPU瓶颈。如果是NVMe SSD确保它安装在主板直连CPU的M.2插槽上而不是芯片组提供的插槽。使用lspci -vv检查PCIe链路速度和宽度如Speed 16GT/s, Width x4。同时使用top或htop观察测试时CPU使用率如果单个核心的sys使用率接近100%可能是单核处理I/O中断的能力到顶了可以尝试调整内核I/O调度器或中断亲和性这属于高级调优。场景二随机读写IOPS上不去延迟很高可能原因1磁盘本身性能极限。首先确认磁盘类型。SATA SSD的随机IOPS极限通常在10万以下而NVMe SSD可以轻松达到几十万甚至上百万。对照磁盘的官方规格书检查。可能原因2队列深度不足。这是最常见的原因。机械硬盘和低端SATA SSD的并发能力弱iodepth1或iodepth8可能就饱和了。但高端NVMe SSD需要很高的队列深度才能发挥性能。做一个实验固定其他参数逐步增加-iodepth1, 8, 16, 32, 64, 128观察IOPS和延迟的变化。你会看到一个曲线IOPS随队列深度增加而上升到达某个点后趋于平缓同时平均延迟会逐步上升。那个拐点就是这块盘在当前负载下的“最佳队列深度”。可能原因3文件系统或挂载选项的影响。在Ext4文件系统上测试与在XFS或Btrfs上测试结果可能有差异。某些挂载选项如noatime、nodiratime可以减少元数据更新开销可能提升性能。可以尝试在原始块设备如/dev/nvme0n1和文件系统上的文件分别测试对比差异。场景三测试结果波动很大延迟“长尾”严重可能原因1磁盘正在执行垃圾回收GC或TRIM。这是SSD的特性。在长时间持续写入后突然进行测试SSD内部可能在后台进行垃圾回收会导致性能骤降和延迟飙升。为了获得稳定性能工业上常用“预处理”方法先用-rwwrite模式写满整个磁盘两遍让SSD进入一个稳定的“脏盘”状态然后再进行正式测试。可能原因2系统后台活动干扰。确保测试时没有其他大型应用在运行。可以使用iotop、vmstat 1等命令监控系统整体的I/O情况。可能原因3散热问题导致降频。高性能NVMe SSD发热很大如果散热不好可能会触发温度保护而降低性能。监控磁盘温度使用smartctl -a /dev/nvme0n1或nvme smart-log /dev/nvme0n1确保测试期间温度在合理范围。一个实用的调优流程基线测试用一套标准参数如4k randread, iodepth1, numjobs1跑一次记录结果。这是磁盘的“单线程单队列”基础性能。压力探索固定bs和rw逐步增加iodepth和numjobs绘制出IOPS/带宽随并发度变化的曲线找到性能拐点。瓶颈分析在性能拐点附近观察cpu使用率特别是sys、ctx切换次数、以及磁盘的util利用率在输出最后的Disk stats里如果持续接近100%说明磁盘已是瓶颈。对比验证调整可能的影响因素如文件系统、挂载选项、内核I/O调度器重复测试对比结果。真实模拟根据你的应用特点如数据库是70%读30%写4k-16k随机设计混合负载测试观察在真实压力模型下的表现。记住fio给出的数字是“实验室数据”它揭示了磁盘的潜力。真正的性能调优是将这些数据与你实际应用的访问模式结合起来通过调整应用配置如数据库的innodb_buffer_pool_size、系统参数如vm.dirty_ratio甚至硬件选型来让整个系统跑得更顺畅。这个过程没有银弹需要反复的测试、观察和调整。但有了fio这个强大的工具你至少不再是盲人摸象而是有了精确的测量仪器能清楚地知道每一次调整究竟带来了怎样的变化。