简介fio-3.8.zip 是一份开源I/O性能测试工具FIO 3.8版本的源码压缩包适合存储工程师、运维人员及性能调优开发者用于评估SSD、HDD、RAID等设备的读写吞吐、延迟与稳定性。压缩包共433个文件以C语言源码148个.c、头文件164个.h及fio配置文件58个.fio为主另有Makefile、shell脚本、Python绘图脚本与文档等便于定制编译和二次开发包体约872KB。已有1628人下载学习。解压并完成make与make install后可借助内置job示例快速开展顺序读写、随机读写、混合负载等多种压测场景同时提供fio2gnuplot、fio_generate_plots等辅助脚本便于将日志转化为可视化图表深入分析IOPS、延迟分布及稳态表现是存储选型、系统调优和故障排查的实用工具。 fio-3.8.zip 这串字符懂的人看一眼就知道是干嘛的fioFlexible I/O Tester3.8 版的安装包。它是存储性能测试领域的老牌工具用来测量磁盘、SSD、文件系统在不同负载下的带宽、IOPS 和延迟。很多人第一次接触它就是因为在压测环境里拿到这个 zip 包却不知道该怎么装、怎么跑、怎么看结果。这篇文章就围绕 fio-3.8.zip 从安装到实战做一次完整梳理Windows 和 Linux 都覆盖适合刚入门的运维、后端开发也适合想在老机器上做磁盘体检的普通用户。1. 先搞清楚 fio-3.8.zip 到底是个什么东西1.1 fio 是什么能解决什么问题fio 全称 Flexible I/O Tester是内核 IO 层开发者维护的开源基准测试工具。它的核心能力是把一块磁盘的真实性能“测出来”顺序读能跑多快、随机写能承受多少 IOPS、99 分位延迟有多高这些直接影响数据库和文件服务的选型。常见使用场景包括对比不同品牌的 SSD、机械盘性能决定采购哪一款。云厂商给的云盘规格不知真假用 fio 拉一遍真实带宽。上线前给服务器磁盘做压测判断是否达到预期。文件系统参数调优后验证是否真的有收益。fio 3.8 大约是 2018 年前后发布的版本后面还有 4.x、5.x但 3.8 在很多内网镜像、教学资料和存量脚本里依然常见。它不算新但足够稳定功能上覆盖日常压测绰绰有余。拿到 fio-3.8.zip 这个包意味着你手里是一份完整的发行归档里面通常包含可执行文件、动态库和文档不用依赖在线仓库非常适合离线环境。1.2 为什么我建议用 zip 包而不是去编译源码Linux 上很多人习惯用 apt install fio 或者下载源码 tar 包自己编译但 zip 包分发是另一种很务实的选择。这里我列个对比方式优点缺点apt/yum 安装自动解决依赖命令简单版本通常较旧不好精确锁定版本源码 tar 包编译可定制编译选项能安装到任意路径依赖 gcc、libaio-devel 等工具链耗时zip 预编译包解压即用跨平台离线友好需要匹配系统架构可能缺动态库Docker 镜像环境隔离一次封装到处跑挂载磁盘和权限配置略麻烦我个人偏好 zip 包的一个重要原因在于“版本可复现”。压测团队如果每人装的 fio 版本不同同一块盘跑出来的输出字段可能都不一样报告很难对齐。把 fio-3.8.zip 放进共享网盘大家统一解压到固定目录输出格式完全一致这才是基准测试该有的严谨性。2. 解压安装与环境准备三分钟跑通 fio2.1 Windows 下解压即用Windows 下拿到 fio-3.8.zip 是最省心的。直接右键解压到某个固定目录比如 D:\tools\fio-3.8目录里会有 fio.exe、几个 DLL 文件、README 和 HOWTO 文档。打开 CMD 或 PowerShell进入目录执行.\fio.exe --version能打印出 fio-3.8 就说明环境没问题。我建议做两件事第一把 D:\tools\fio-3.8 加入系统 PATH 环境变量这样以后不用每次都 cd 进去第二如果杀毒软件报警别急着删先看是不是 fio.exe 因为 IO 驱动行为被误判把目录加入白名单即可。fio 在 Windows 上的异步 IO 引擎是 windowsaio如果你从网上抄命令时用了 libaio会直接报错这一点后面会专门讲。2.2 Linux 下从 zip 包安装两种路线Linux 下面情况稍微复杂一点要先确认 zip 里装的是什么。很多发行版提供的是“源码 zip”也就是需要自己编译的少数会提供编译好的二进制。先用 unzip 解包unzip fio-3.8.zip -d /opt/fio cd /opt/fio如果系统没有 unzip先装一下CentOS 系是 yum install unzipUbuntu/Debian 是 apt install unzip。解压后看目录里有没有 configure 文件。如果有说明是源码包走编译路线yum install -y gcc make libaio-devel zlib-devel ./configure make -j$(nproc) make install这样装完默认的 fio 在 /usr/local/bin/fio。如果想装到指定目录configure 时用 --prefix/opt/fio-build 指定即可。如果解压出来直接有 fio 可执行文件说明是二进制包确认一下系统架构uname -m是否匹配然后直接运行。不过说实话Linux 下预编译二进制容易踩 glibc 版本匹配的坑真要长期用我还是推荐在自己机器上编一遍最稳妥。2.3 解压踩坑EOCD、分卷和权限zip 包在实际使用中最大的敌人不是体积大而是“静默损坏”。很多人在解压时遇到过invalid zip archive: could not find eocd这种报错这里 eocd 是 End of Central Directory 的缩写也就是 zip 文件末尾的中心目录结束标记。如果 zip 文件下载不完整、FTP 传输时用了文本模式、或者拷贝过程中丢字节都会导致这个标记找不到解压工具直接拒绝工作。我的处理经验是先看文件大小和官方 MD5/SHA256 是否一致不一致就重新下载然后换 7-Zip 或者命令行 unzip 再试一次Windows 自带解压有时比第三方工具更严格反而容易误报。还有一个小场景分发大包时有人用了分卷压缩解压时提示“必须有下列压缩分卷 z01”这时候要把所有 .z01、.z02 和主 zip 文件放在同一个目录里从第 1 个分卷开始解压缺一个分卷都不行。另外解压到 Linux 的 /root 或 /opt 目录时要用有权限的账号否则会遭遇zip warning: not all files were readable虽然警告不致命但会导致某些文档缺失后续查参考手册时才发现少了文件就尴尬了。解压完成后我习惯跑一遍fio --version和fio --help确保主程序和动态库都完整可用。3. 核心实战用 fio-3.8 测磁盘性能3.1 顺序读测试先确认带宽顺序读是最直观的测试衡量磁盘在连续读取大块数据时能跑多快单位是 MB/s 或者 GiB/s。下面这条命令我经常用来给磁盘“热热身”fio --nameseqread --ioenginelibaio --direct1 --rwread --bs1M --size8G --numjobs1 --runtime60 --group_reporting拆开看每个参数的含义--nameseqread这个 job 的名字随便起输出里会带。--ioenginelibaioLinux 下的异步 IO 引擎能发挥出磁盘真实并发能力。--direct1绕过操作系统页缓存直接读写磁盘避免测试结果被内存缓存污染。--rwread纯顺序读。--bs1M块大小 1MiB测顺序带宽时通常用大块1M 或 4M 都行。--size8G测试文件总大小 8GiB。如果机器内存是 16G建议至少选 32G保证文件容量超过内存否则缓存效应会让数据虚高。--runtime60最多跑 60 秒到点自动结束。--group_reporting多个 job 的结果汇总成一组输出更简洁。跑完后看 BW 那一行比如BW731.4MiB/s (767MB/s)说明顺序读大约 731MiB/s。3.2 随机写测试盯紧 IOPS数据库的在线日志写入、缓存落盘场景本质上都是随机小 IO。随机写的核心指标是 IOPS也就是每秒能处理多少个 IO 请求。测随机写的命令长这样fio --namerandwrite --ioenginelibaio --direct1 --rwrandwrite --bs4k --size4G --iodepth32 --runtime60 --group_reporting这里bs4k模拟数据库常见的 4KiB 小块写入iodepth32表示同时有 32 个 IO 请求在排队。磁盘能维持多少 IOPS主要看这个参数和硬件能力。输出结果里IOPS45678这样的数据就是每秒 IO 次数越高越好。如果是 SSD随机写 IOPS 普遍在几万甚至几十万如果是机械硬盘能到几百就已经不错了。实际业务中读写不会完全分开我在压测时更常用--rwrandrw --rwmixread70让读写比例接近 70:30模拟混合负载。测试混合场景时建议把--size和--runtime同时设上防止因为某一段磁盘提前写满导致结果失真。3.3 这些参数到底怎么选很多新手拿到 fio 命令后不知道该调哪些参数我按优先级说说。第一--size和--runtime必须至少有一个。如果只写 size测试会一直跑到文件写完如果文件特别大可能几个小时都跑不完。生产环境压测我习惯都会加--runtime60 --time_based保证单次测试时间可控。time_based的意思是“哪怕文件写完了也继续测满 runtime 时长”适合对磁盘做持续压力验证。第二--iodepth不是越大越好。它代表请求队列深度相当于水管里同时排放的水量。对于 SATA SSD32 到 64 通常就能测出峰值对于 NVMe可以尝试 128 或 256。但注意如果--iodepth设太高而磁盘和驱动跟不上压测软件本身反而会成为瓶颈数据看起来“稳定”但其实是假的。第三--numjobs和--iodepth是乘法关系总并发数 iodepth × numjobs。测单盘性能时 numjobs1 就够测文件系统并发能力时再增加。我见过有人为了压满 32 核机器直接 numjobs64结果整个服务器 CPU 被打满性能数据完全没法看最后只能重启。第四--direct1是压测铁律。direct0时数据会经过 Page Cache小文件随机读可能被缓存命中测出来的结果比真实硬件高一个数量级。除非你故意想测文件系统带缓存的综合表现否则一定要用 direct1。4. 测试结果解读与高频问题排查4.1 几行输出把磁盘底细看明白fio 跑完后会输出一大段结果新手容易看晕但核心就几个字段。参考一段简化输出read: IOPS45.6k, BW178MiB/s (187MB/s)(10700MiB/60.01msec) slat (usec): min3, max278, avg12.54, stdev8.12 clat (usec): min120, max12800, avg632.11, stdev481.32 lat (usec): min140, max12900, avg645.23, stdev483.91 clat percentiles (usec): | 1.00th[ 248], 5.00th[ 352], 50.00th[ 611], | 90.00th[ 956], 99.00th[ 1344], 99.90th[ 2030], | 99.99th[ 3146]IOPS是每秒 IO 次数。BW是带宽注意括号里可能同时打印 MiB/s 和 MB/s别混用。slat是提交延迟从 fio 发出 IO 到内核接受的时间通常在微秒级。clat是完成延迟从提交到完成的耗时这是衡量磁盘响应速度最关键的数据。clat percentiles表示百分位延迟比如99.00th[1344]表示 99% 的请求在 1344 微秒以内完成对应 1.344 毫秒。数据库场景里P99 延迟比平均延迟更能反映真实体验。如果测试过程中看到CRC error或者mismatch字样说明出现了数据校验失败这是磁盘或文件系统问题的强烈信号别再继续跑大规模压测了先备份数据换盘检查。4.2 运行环境高频报错修复记录我在不同机器上跑 fio 时踩过不少坑整理成一张速查表报错或现象常见原因解决方案fio: --ioenginelibaio not available系统没装 libaio 库安装 libaio / libaio-dev或改用--ioenginepsynclibaio.so: cannot open shared object file动态库缺失Linux 上装 libaio并确保 ldconfig 已刷新could not find eocdzip 文件损坏或下载不完整重新下载并校验 MD5换 7-Zip 解压zip warning: not all files were readable解压时有文件权限不够或被占用root 权限重新解压释放占用文件的进程测试结果不稳定重复跑差很大direct0、有后台任务、文件缓存干扰加--direct1关闭无关进程测试文件放在独立磁盘Windows 下报 ioengine 不可用命令里用了 libaio改成--ioenginewindowsaio无法打开裸设备权限不足Linux 用 rootWindows 管理员终端运行程序直接卡死无输出size 设太大且没设 runtime强制加--runtime60 --time_based先跑小文件验证这里重点说一个容易误导人的地方libaio和psync的测试含义完全不同。psync是同步 IO一次只发一个请求测出来的 IOPS 会远低于libaio但它在很多容器和受限环境里是唯一能用的引擎。如果只是做横向对比必须保证所有机器用同一个 ioengine否则数据没有可比性。裸设备测试也值得多提一句。fio 可以直接测试块设备例如/dev/sdb这样能绕过文件系统测出最原始的硬件能力。但千万注意用--filename/dev/sdb --direct1会直接覆盖设备上的数据操作前必须确认没用到重要数据。我们生产环境会先用lsblk和blkid把磁盘信息核对三遍才敢动手。5. 一些个人经验与建议我自己做过不少存储选型和性能验证的活儿最后分享三个实际体会。第一个体会压测前一定要统一版本。fio 3.8 和 4.x 输出格式有差异团队里有人用 3.8、有人用 4.2最后拉数据对比时会发现格式对不上光写解析脚本就浪费半天。现在我把 fio-3.8.zip 放进公司内部的工具镜像所有人解压到同一目录跑同一套 job 文件结果直接对齐。第二个体会多用 JSON 输出别只靠人眼盯终端。fio 支持--output-formatjson跑完把结果保存成文件再用脚本提取 IOPS、带宽和 P99 延迟这样就能自动汇总多台机器的测试报告fio --namerandomread --ioenginelibaio --direct1 --rwrandread --bs4k --size4G --iodepth32 --runtime60 --output-formatjson --outputresult.json我习惯每次压测都把机器型号、系统内核、磁盘型号、fio 版本写进 JSON 文件名里比如modelA_3.10_ssd_fio38.json后面复盘时一眼就能看出哪组数据的上下文是什么。第三个体会是给普通用户的小建议别看不起老机器拿 U 盘装一个 fio-3.8到现场解压、跑一条随机读命令几分钟就能判断磁盘是不是真的不行。我帮朋友排查过两台“开机慢、软件卡”的老电脑跑完发现其中一台机械盘随机读 IOPS 只有 40明显是盘片老化换 SSD 之后像换了台新机器。用工具量化性能问题比拍脑袋换硬件靠谱得多。最后再补充一个小技巧fio 3.8 支持通过 job 文件批量定义测试场景。你可以把顺序读、随机写、混合读写分别写成三个 .job 文件用fio seqread.job randwrite.job一次性顺序执行比在命令行里堆一长串参数更清晰也更方便团队共享和后续维护。本文还有配套的精品资源点击获取
