简介：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 这串字符，懂的人看一眼就知道是干嘛的：fio（Flexible I/O Tester）3.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. 解压安装与环境准备：三分钟跑通 fio
2.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 unzip，Ubuntu/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 --name=seqread --ioengine=libaio --direct=1 --rw=read --bs=1M --size=8G --numjobs=1 --runtime=60 --group_reporting拆开看每个参数的含义：
--name=seqread：这个 job 的名字，随便起，输出里会带。--ioengine=libaio：Linux 下的异步 IO 引擎，能发挥出磁盘真实并发能力。--direct=1：绕过操作系统页缓存，直接读写磁盘，避免测试结果被内存缓存污染。--rw=read：纯顺序读。--bs=1M：块大小 1MiB，测顺序带宽时通常用大块，1M 或 4M 都行。--size=8G：测试文件总大小 8GiB。如果机器内存是 16G，建议至少选 32G，保证文件容量超过内存，否则缓存效应会让数据虚高。--runtime=60：最多跑 60 秒，到点自动结束。--group_reporting：多个 job 的结果汇总成一组，输出更简洁。
跑完后看 BW 那一行，比如BW=731.4MiB/s (767MB/s)，说明顺序读大约 731MiB/s。
3.2 随机写测试：盯紧 IOPS
数据库的在线日志写入、缓存落盘场景，本质上都是随机小 IO。随机写的核心指标是 IOPS，也就是每秒能处理多少个 IO 请求。测随机写的命令长这样：
fio --name=randwrite --ioengine=libaio --direct=1 --rw=randwrite --bs=4k --size=4G --iodepth=32 --runtime=60 --group_reporting这里bs=4k模拟数据库常见的 4KiB 小块写入，iodepth=32表示同时有 32 个 IO 请求在排队。磁盘能维持多少 IOPS，主要看这个参数和硬件能力。
输出结果里IOPS=45678这样的数据就是每秒 IO 次数，越高越好。如果是 SSD，随机写 IOPS 普遍在几万甚至几十万；如果是机械硬盘，能到几百就已经不错了。
实际业务中读写不会完全分开，我在压测时更常用--rw=randrw --rwmixread=70，让读写比例接近 70:30，模拟混合负载。测试混合场景时，建议把--size和--runtime同时设上，防止因为某一段磁盘提前写满导致结果失真。
3.3 这些参数到底怎么选
很多新手拿到 fio 命令后，不知道该调哪些参数，我按优先级说说。
第一，--size和--runtime必须至少有一个。如果只写 size，测试会一直跑到文件写完；如果文件特别大，可能几个小时都跑不完。生产环境压测我习惯都会加--runtime=60 --time_based，保证单次测试时间可控。time_based的意思是“哪怕文件写完了也继续测满 runtime 时长”，适合对磁盘做持续压力验证。
第二，--iodepth不是越大越好。它代表请求队列深度，相当于水管里同时排放的水量。对于 SATA SSD，32 到 64 通常就能测出峰值；对于 NVMe，可以尝试 128 或 256。但注意，如果--iodepth设太高而磁盘和驱动跟不上，压测软件本身反而会成为瓶颈，数据看起来“稳定”但其实是假的。
第三，--numjobs和--iodepth是乘法关系，总并发数 = iodepth × numjobs。测单盘性能时 numjobs=1 就够，测文件系统并发能力时再增加。我见过有人为了压满 32 核机器，直接 numjobs=64，结果整个服务器 CPU 被打满，性能数据完全没法看，最后只能重启。
第四，--direct=1是压测铁律。direct=0时数据会经过 Page Cache，小文件随机读可能被缓存命中，测出来的结果比真实硬件高一个数量级。除非你故意想测文件系统带缓存的综合表现，否则一定要用 direct=1。
4. 测试结果解读与高频问题排查
4.1 几行输出，把磁盘底细看明白
fio 跑完后会输出一大段结果，新手容易看晕，但核心就几个字段。参考一段简化输出：
read: IOPS=45.6k, BW=178MiB/s (187MB/s)(10700MiB/60.01msec) slat (usec): min=3, max=278, avg=12.54, stdev=8.12 clat (usec): min=120, max=12800, avg=632.11, stdev=481.32 lat (usec): min=140, max=12900, avg=645.23, stdev=483.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: --ioengine=libaio not available | 系统没装 libaio 库 | 安装 libaio / libaio-dev，或改用--ioengine=psync |
libaio.so: cannot open shared object file | 动态库缺失 | Linux 上装 libaio，并确保 ldconfig 已刷新 |
could not find eocd | zip 文件损坏或下载不完整 | 重新下载并校验 MD5，换 7-Zip 解压 |
zip warning: not all files were readable | 解压时有文件权限不够或被占用 | root 权限重新解压，释放占用文件的进程 |
| 测试结果不稳定，重复跑差很大 | direct=0、有后台任务、文件缓存干扰 | 加--direct=1，关闭无关进程，测试文件放在独立磁盘 |
| Windows 下报 ioengine 不可用 | 命令里用了 libaio | 改成--ioengine=windowsaio |
| 无法打开裸设备 | 权限不足 | Linux 用 root，Windows 管理员终端运行 |
| 程序直接卡死无输出 | size 设太大且没设 runtime | 强制加--runtime=60 --time_based，先跑小文件验证 |
这里重点说一个容易误导人的地方：libaio和psync的测试含义完全不同。psync是同步 IO，一次只发一个请求，测出来的 IOPS 会远低于libaio，但它在很多容器和受限环境里是唯一能用的引擎。如果只是做横向对比，必须保证所有机器用同一个 ioengine，否则数据没有可比性。
裸设备测试也值得多提一句。fio 可以直接测试块设备，例如/dev/sdb，这样能绕过文件系统，测出最原始的硬件能力。但千万注意，用--filename=/dev/sdb --direct=1会直接覆盖设备上的数据，操作前必须确认没用到重要数据。我们生产环境会先用lsblk和blkid把磁盘信息核对三遍才敢动手。
5. 一些个人经验与建议
我自己做过不少存储选型和性能验证的活儿，最后分享三个实际体会。
第一个体会：压测前一定要统一版本。fio 3.8 和 4.x 输出格式有差异，团队里有人用 3.8、有人用 4.2，最后拉数据对比时会发现格式对不上，光写解析脚本就浪费半天。现在我把 fio-3.8.zip 放进公司内部的工具镜像，所有人解压到同一目录，跑同一套 job 文件，结果直接对齐。
第二个体会：多用 JSON 输出，别只靠人眼盯终端。fio 支持--output-format=json，跑完把结果保存成文件，再用脚本提取 IOPS、带宽和 P99 延迟，这样就能自动汇总多台机器的测试报告：
fio --name=randomread --ioengine=libaio --direct=1 --rw=randread --bs=4k --size=4G --iodepth=32 --runtime=60 --output-format=json --output=result.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一次性顺序执行，比在命令行里堆一长串参数更清晰，也更方便团队共享和后续维护。
本文还有配套的精品资源，点击获取
