之前帮朋友排查一台数据库服务器的性能问题磁盘读写看起来不高但查询就是慢。我一开始用 dd 测速数字很正常后来换 iozone 这款磁盘读写测试工具把文件大小和记录长度交叉测了一遍才发现小随机写完全不行问题出在文件系统挂载参数上。从那以后只要涉及存储性能摸底iozone 就是我的第一选择。这篇就把 iozone 的下载安装、常用命令参数、实战用法和结果解读完整梳理一遍给第一次接触的朋友一条能直接跑通的路也给用过但没细究过的朋友一些可以直接抄的测试模板。1. 先用一页纸搞清楚iozone 到底能测哪些读写模式1.1 一张表看懂内置的测试模式iozone 的核心价值在于它不是只测一个顺序写或顺序读而是通过-i参数选择不同测试项目。每一项都对应着一种应用访问模式。测试编号测试项模拟的业务场景0write/rewrite顺序写新文件、覆盖写已有文件1read/re-read顺序读新读过的文件、反复读同一文件2random read/write随机读、随机写数据库索引扫描类负载3read-backwards逆序读日志回放等场景4re-write-record固定记录大小重写适合分析碎片化写入5stride-read跨步读固定间隔跳跃读取6/7fwrite/fread用 C 标准库函数做写/读考验用户态缓冲8random mix随机混合读写模拟邮件服务器、文件服务器9~12pwrite/pread/pwritev/preadv定位写、定位读、向量读写跑测试之前先想清楚你的业务最接近哪种模式如果是一个 MySQL 实例重点看 0、2、8如果是视频点播类服务重点看 0、1、5。测试项选错后面的数据基本没有参考价值。1.2 dd 为什么测不出真相你在搜索引擎上随手一翻满屏都是dd if/dev/zero of/tmp/test bs1M count1024的测速命令。这行命令测出来的往往不是文件系统真实性能而是页面缓存把脏页吞掉的速度。dd 默认不走 Direct IO数据先落到 page cache操作系统认为写入已经完成真正落盘是后台异步的事。就算加了oflagdirect绕过缓存也只是把文件系统缓冲、预读这些行为全部绕开得到的数字依然偏向极端。更关键的问题是dd 只测一个文件大小、一个块大小、一种访问模式。实际业务访问存储时文件大小和 IO 大小几乎不会一成不变。iozone 的价值就是把文件大小、记录长度、读写模式三个维度同时展开跑出一张矩阵让你一眼看到性能拐点到底在哪。1.3 和 fio 比iozone 的定位更轻量肯定有人会提 fio。fio 功能更强能精细控制 ioengine、队列深度、混合读写比例做深度调优时确实是更好的工具。可 fio 的学习成本高配置要写 job 文件单纯想快速判断一块盘或一个文件系统能否满足业务需求时iozone 的开箱即用反而更适合。我的习惯是初步摸底用 iozone 自动模式快速拿到整体读写画像发现问题需要深挖时再用 fio 做针对性验证。两者不是对立关系而是上下游关系。2. 下载安装与首次运行三步把 iozone 跑起来2.1 从官网拿源码包并编译安装iozone 官方发布入口在iozone.org的src/current目录。我一般直接下载源码包自己编译比到处找编译好的二进制靠谱。wget https://www.iozone.org/src/current/iozone3_506.tar tar xvf iozone3_506.tar cd iozone3_506/src/current make linux sudo cp iozone /usr/local/bin/拿到源码包先别急着 make看一眼 README 和 Makefile 里的平台列表。x86_64 的 Linux 环境直接make linux就能编出来旧版本或特殊架构可能要选linux-64、linux-itanium这类目标。编出来的可执行文件就叫iozone放到/usr/local/bin下方便全局调用。如果官网连接不稳部分 Linux 发行版的软件源里也有 iozone。Ubuntu/Debian 可以直接sudo apt install iozone3CentOS/RHEL 用 EPEL 源里的 iozone 也行。能用包管理器装就优先用包管理器省得自己去处理编译依赖。2.2 Windows 和 macOS 下的快速使用Windows 上没必要编译iozone 官网在 Windows 目录里提供了编译好的执行文件名字一般是wire32.exe和wire64.exe。以管理员身份打开 cmd切到解压目录直接跑wire64.exe -i 0 -i 1 -s 1G -r 4k -f C:\tmp\iozone.tmpmacOS 上源码包同样能编译进入src/current后执行make macosx再把生成的iozone复制到/usr/local/bin。如果你用 Homebrew也可以尝试brew install iozone但 Homebrew 的配方更新不算勤快真要最新版还是走源码编译。2.3 装好后先跑一条冒烟命令验证安装完之后不要直接跑大测试先来一条很小的冒烟命令确认工具本身没问题iozone -i 0 -i 1 -s 16M -r 4k -f /tmp/iozone_smoke.tmp-i 0 -i 1指定只测顺序写和顺序读-s 16M指定单文件大小-r 4k指定记录长度-f指定测试文件路径。跑完会输出 write、rewrite、read、reread 四类结果。能看到数字出来说明工具已经能正常工作接下来才进入正式的测试参数设计。3. 命令参数详解理解这些标志才能组合出有效测试3.1 常用参数速查表iozone 手册翻一遍会发现参数非常多但日常真正高频用到的就下面这些参数含义典型用法说明-a自动模式自动生成文件大小与记录长度组合-i N指定测试项可多次出现比如 -i 0 -i 1-s size测试文件大小支持 m/g 后缀比如 -s 4g-r size记录长度模拟应用单次 IO 大小比如 -r 4k-f file测试文件路径指定单个测试文件位置-F f1 f2 ...多文件路径多线程模式下每个线程一个文件-t N并发线程数和 -F 配合模拟并发压力-n size自动模式起始文件大小控制自动模式测试范围-g size自动模式最大文件大小控制自动模式测试上限-y size自动模式最小记录长度控制记录长度下界-q size自动模式最大记录长度控制记录长度上界-b file输出 Excel 兼容报告配合 -R 生成 .xls 文件-RExcel 格式输出配合 -b 使用-I使用 Direct IO绕过 page cache测真实设备能力-e每次写后 flush把脏数据强制刷下去-c每次写后关闭文件模拟真实文件开关行为-O使用 O_SYNC每次写入同步落盘结果偏保守注意-n、-g、-y、-q只有在自动模式下才有意义。手动模式直接用-s、-r指定一组值不要混着乱用否则结果容易被误解。3.2 文件大小、记录长度和缓存之间的三角关系这是 iozone 使用里面最重要的一个概念我单独拿出来说。文件大小-s决定测试能否越过页面缓存。页面缓存是会“作弊”的当测试文件小于系统可用内存时文件内容很可能完全驻留在内存里后续读写命中的全是内存速度而不是磁盘速度。做设备性能摸底时文件大小至少应该是物理内存的两倍。一台 16G 内存的机器把-s设成 32G 甚至 64G才能让大部分测试落在真实磁盘上。记录长度-r代表应用单次 IO 的大小是最能体现业务特征的一个参数。数据库的日志写一般偏小4K 到 64K文件服务器常见的块大小是 4K 到 1M大文件流媒体则偏向 1M 以上。记录长度选小了系统调用次数和锁竞争会明显拉低结果选大了又会掩盖小 IO 下的真实延迟。文件大小和记录长度要匹配。用 4K 的记录长度去测 128G 文件随机写模式会跑出天文数字一样的测试时间用 1M 记录长度去测 64M 小文件又会因为文件本身太小根本体现不出 IO 引擎的完整能力。自动模式里 iozone 会按照固定比例生成组合目的就是避免这种错配。3.3 自动模式如何控制范围别拿默认配置直接跑-a模式默认覆盖的文件大小范围很大记录长度也会从 4K 一路自增到 16M。如果你直接跑iozone -a磁盘容量有限或时间有限时一跑就是几个小时很正常。这个时候用-n、-g、-y、-q四个参数把范围收敛。iozone -a -n 1G -g 16G -y 4k -q 1M -i 0 -i 1 -i 2这条命令的含义是文件大小从 1G 开始测到 16G记录长度只测 4K 到 1M 之间的几个档位测试项目只保留顺序写、顺序读和随机读写。相比裸-a时间可控得多。我在生产环境摸底时还有一条经验先用小范围快速跑一轮找出性能拐点的大致区间再针对拐点附近的文件大小和记录长度做二次细化测试。上来就追求完整矩阵多半会浪费大把时间。4. 四个可以直接抄的实战场景4.1 场景一新到一台服务器快速做文件系统整体体检新服务器验收我通常会先对挂载目录做一次包含顺序读写和随机读写的整体摸底iozone -R -b /tmp/fs_health.xls -a -g 32G -n 1G -y 4K -q 1M -i 0 -i 1 -i 2 -c -e -f /data/iozone.test解释一下每个参数-R -b组合把结果输出成 Excel 文件方便归档和对比-a启用自动模式-g 32G把最大文件限制在 32G这台机器内存 16G文件上限是内存两倍足以压过缓存-n 1G跳过太小文件避免无意义的短测试-y 4K -q 1M控制记录长度-i 0 -i 1 -i 2只测顺序写、顺序读、随机读写-c每次写入后关闭文件-e每次写入后做 flush这两个参数能让结果更接近真实落盘性能。跑完后重点看随机读写列如果 4K 记录下的随机写明显低于预期再结合 fsync 参数做二次确认。4.2 场景二模拟数据库的小随机读写负载MySQL、PostgreSQL 这类数据库的存储访问集中在不定长页面的随机读写上4K 到 16K 的 IO 占大头。模拟时用多线程更能体现并发场景iozone -R -b /tmp/db_sim.xls -i 2 -i 8 -r 4K -s 16G -t 8 -F /testdir/db1 /testdir/db2 /testdir/db3 /testdir/db4 /testdir/db5 /testdir/db6 /testdir/db7 /testdir/db8 -c -e-i 2是随机读写-i 8是随机混合读写-r 4K固定记录长度-s 16G指定文件大小-t 8开 8 个线程-F为每个线程指定文件。这个组合模拟了 8 个会话同时对数据库文件做随机访问。如果测出来的结果连业务估算的峰值都达不到大概率要考虑换盘或调整存储方案。要提醒一句-t 8配合-F时文件数量必须和线程数一致否则会在启动阶段报错或者部分线程抢同一个文件互相干扰。4.3 场景三视频点播、大文件存储的顺序读写吞吐上限大文件顺序读写主要关心吞吐量直接指定大的记录长度避免小 IO 把结果拉低。以媒体文件场景为例iozone -R -b /tmp/media_seq.xls -i 0 -i 1 -r 1M -s 64G -f /media/iozone.test -I-r 1M模拟流媒体应用的块大小-s 64G保证文件远超内存-I开启 Direct IO 绕过 page cache。这样测出来的就是设备本身的顺序吞吐能力而不是操作系统缓存提前把数据“预热”了。如果同一块盘 Direct IO 结果比普通模式低 20% 以上说明文件系统调优空间可能很大例如预读窗口或 IO scheduler 参数需要调。4.4 场景四多线程并发读写验证文件服务上限公司要做一个小型文件共享服务我想知道这批 SATA 盘能扛住多少人同时读写直接用多文件、多线程模式压一轮iozone -R -b /tmp/share_sim.xls -i 0 -i 1 -i 2 -t 16 -s 4G -r 64K -F /share/test1 /share/test2 /share/test3 /share/test4 /share/test5 /share/test6 /share/test7 /share/test8 /share/test9 /share/test10 /share/test11 /share/test12 /share/test13 /share/test14 /share/test15 /share/test16 -c -e-s 4G是每个线程的文件大小总数据量 64G-r 64K是文件共享服务常见的 IO 块-t 16模拟 16 个客户端同时读写。结果里能看到并发场景下吞吐量是否线性扩展。如果线程数翻倍但吞吐量没涨瓶颈往往在网络或文件系统锁上而不是磁盘本身。实际命令里你要把 16 个路径全部写全用 for 循环生成路径列表更省事。真跑到一半发现某个文件路径不存在整个测试会直接中断。5. 测试结果怎么读别只盯着最后一个数字5.1 看懂控制台输出iozone 默认输出是一串很朴素的文本表。冒烟测试时你会看到类似下面这种File size set to 16384 kB Record size set to 4096 bytes Command line used: iozone -i 0 -i 1 -s 16M -r 4k -f /tmp/iozone_smoke.tmp Output is in kB/s后面跟着的表头一般是文件大小、记录大小、write、rewrite、read、reread 这几列单位是 kB/s。如果开了-b和-R这些内容还会被写进 .xls 报告里。注意单位不是 MB/s读大数字时可以先除 1024 再判断。自动模式下矩阵的行列会随着文件大小和记录长度自动展开。我习惯先把整个结果拉到 Excel 里转成带颜色的热力图颜色最深的地方就是整体性能最优的组合区域颜色断层的位置往往是需要重点关注的性能拐点。5.2 报告里需要重点关注的三类数字在多列报告里我最关注三类数字的差异和变化write 与 rewrite 的差距同一个文件重写比新写差很多说明文件系统分配新块的能力弱可能存在碎片化问题。read 与 reread 的差距首次读明显慢于重复读说明页面缓存命中起了作用如果-e已经开启 flush可能代表预读算法不够主动。随机列在记录长度变化时的曲线随机写吞吐随记录长度增加应当平缓上升如果中间出现断崖式下跌可能是文件系统锁或 IO 调度算法在特定大小下有惩罚。单看一个数字没意义看组合和趋势才有意义。这也是 iozone 相比 dd 最有价值的地方。5.3 怎么判断结果是否正常判断结果是否正常不外乎三条路。第一横向对比同型号设备。把相同命令在同样硬件上跑一遍如果新盘和旧盘差距超过 20%优先考虑固件、驱动或文件系统参数问题。第二纵向对比业务需求。数据库 4K 随机写要求每秒能完成多少次换算成 iozone 的 kB/s 以后是否达标心里要有数。第三和官方标称值比。厂商给的顺序读写数字一般是理想环境下的峰值测试条件差一点很正常。但如果只有标称值的一半不到就该检查 PCIe 通道带宽、线缆、卡口速率这些边界条件。6. 这些坑我都踩过iozone 使用中的常见误区6.1 文件大小小于内存测出的全是 page cache 的速度我刚开始用 iozone 时犯过最典型的错误拿一台 64G 内存的服务器去测一块 NVMe 盘文件大小只设了 8G。测试结果写入速度每秒 3G 以上一度以为买到了神仙盘。后来加了-I重新测实际写入只有 1.5G前者纯是页面缓存把数据吞了。所以规则很简单测设备能力时文件大小至少是物理内存的两倍测文件系统真实行为时配合-e或-I使用更有参考性。6.2 测试盘剩余空间没算清楚中途报错另一类翻车是测试盘空间不够。多线程模式下一开就是 16 个文件每个文件-s 4G一共要 64G 空间。加上文件系统本身要预留至少 5% 的块实际可用空间比df显示的还要少。跑到一半报No space left on device的情况我至少遇到过三次。建议在跑之前用df -h看一眼目标分区剩余空间然后留出至少 10% 余量。如果只是做性能测试测完立刻删掉测试文件别把几个 G 的测试文件留在生产盘上。6.3 你以为关闭了 cache实际没有-I、-O、-e 的区别-I是 Direct IO直接绕过 page cache-O是 O_SYNC让每次写入同步落盘-e是测试结束后 flush。三者都影响缓存但作用位置完全不同。实际测试时-I的数字代表“设备在不使用系统缓存时的能力”偏向硬件极限-O的数字代表“每次写入都等待落盘确认”的性能偏向数据库日志这类对持久性要求高的场景-e更像工程上的折中。搞混这三者看到两种结果不一致就开始怀疑硬件坏了其实是测的定义不一样。6.4 自动模式一跑就是几小时怎么优化iozone -a看起来简单默认范围其实非常大。文件大小从 64K 一路放大到内存大小甚至更多记录长度又从 4K 一路放到 16M再加上默认测试项多时间非常可观。解决办法是用-n -g -y -q把范围锁死。还有一个取巧的办法先用小范围跑一轮比如-n 1G -g 8G -y 4K -q 256K找到明显拐点再针对拐点周围做细分。这样比强行把完整矩阵跑完省时得多。6.5 网络文件系统上的测试注意“双层缓存”如果测试对象是 NFS、CIFS 这类网络文件系统iozone 结果很容易被两层缓存污染一层是客户端 page cache另一层是服务端 cache。要在客户端加-I或者-e尽量绕过本地缓存同时在服务端用iostat观察真实盘活。另外网络文件系统测试对网络延迟很敏感同一个网络文件系统在不同网段下测出来的数字差异很大。做对比测试时客户端和服务端的网络路径必须一致否则对比没有任何意义。iozone 这个工具刚接触时可能觉得参数多、输出乱不好上手。可一旦把文件大小、记录长度、缓存策略这几个核心概念想明白它就能变成一个非常顺手的存储摸底工具。我个人现在每次给新服务器做验收都会固定跑一遍 iozone然后把 .xls 报告存档下次遇到性能问题直接翻出来对比。最后再分享一个小习惯测试前先sync一次把系统里的脏页刷掉测试文件一定放到被测的目标文件系统上别放到系统盘测试完把报告命名带上日期、盘型、挂载方式比如fs_health_20250115_sata_ext4.xls积累半年以后回看你会感谢当时这个命名习惯。
iozone磁盘读写测试工具实战：从安装参数到性能结果解读
之前帮朋友排查一台数据库服务器的性能问题磁盘读写看起来不高但查询就是慢。我一开始用 dd 测速数字很正常后来换 iozone 这款磁盘读写测试工具把文件大小和记录长度交叉测了一遍才发现小随机写完全不行问题出在文件系统挂载参数上。从那以后只要涉及存储性能摸底iozone 就是我的第一选择。这篇就把 iozone 的下载安装、常用命令参数、实战用法和结果解读完整梳理一遍给第一次接触的朋友一条能直接跑通的路也给用过但没细究过的朋友一些可以直接抄的测试模板。1. 先用一页纸搞清楚iozone 到底能测哪些读写模式1.1 一张表看懂内置的测试模式iozone 的核心价值在于它不是只测一个顺序写或顺序读而是通过-i参数选择不同测试项目。每一项都对应着一种应用访问模式。测试编号测试项模拟的业务场景0write/rewrite顺序写新文件、覆盖写已有文件1read/re-read顺序读新读过的文件、反复读同一文件2random read/write随机读、随机写数据库索引扫描类负载3read-backwards逆序读日志回放等场景4re-write-record固定记录大小重写适合分析碎片化写入5stride-read跨步读固定间隔跳跃读取6/7fwrite/fread用 C 标准库函数做写/读考验用户态缓冲8random mix随机混合读写模拟邮件服务器、文件服务器9~12pwrite/pread/pwritev/preadv定位写、定位读、向量读写跑测试之前先想清楚你的业务最接近哪种模式如果是一个 MySQL 实例重点看 0、2、8如果是视频点播类服务重点看 0、1、5。测试项选错后面的数据基本没有参考价值。1.2 dd 为什么测不出真相你在搜索引擎上随手一翻满屏都是dd if/dev/zero of/tmp/test bs1M count1024的测速命令。这行命令测出来的往往不是文件系统真实性能而是页面缓存把脏页吞掉的速度。dd 默认不走 Direct IO数据先落到 page cache操作系统认为写入已经完成真正落盘是后台异步的事。就算加了oflagdirect绕过缓存也只是把文件系统缓冲、预读这些行为全部绕开得到的数字依然偏向极端。更关键的问题是dd 只测一个文件大小、一个块大小、一种访问模式。实际业务访问存储时文件大小和 IO 大小几乎不会一成不变。iozone 的价值就是把文件大小、记录长度、读写模式三个维度同时展开跑出一张矩阵让你一眼看到性能拐点到底在哪。1.3 和 fio 比iozone 的定位更轻量肯定有人会提 fio。fio 功能更强能精细控制 ioengine、队列深度、混合读写比例做深度调优时确实是更好的工具。可 fio 的学习成本高配置要写 job 文件单纯想快速判断一块盘或一个文件系统能否满足业务需求时iozone 的开箱即用反而更适合。我的习惯是初步摸底用 iozone 自动模式快速拿到整体读写画像发现问题需要深挖时再用 fio 做针对性验证。两者不是对立关系而是上下游关系。2. 下载安装与首次运行三步把 iozone 跑起来2.1 从官网拿源码包并编译安装iozone 官方发布入口在iozone.org的src/current目录。我一般直接下载源码包自己编译比到处找编译好的二进制靠谱。wget https://www.iozone.org/src/current/iozone3_506.tar tar xvf iozone3_506.tar cd iozone3_506/src/current make linux sudo cp iozone /usr/local/bin/拿到源码包先别急着 make看一眼 README 和 Makefile 里的平台列表。x86_64 的 Linux 环境直接make linux就能编出来旧版本或特殊架构可能要选linux-64、linux-itanium这类目标。编出来的可执行文件就叫iozone放到/usr/local/bin下方便全局调用。如果官网连接不稳部分 Linux 发行版的软件源里也有 iozone。Ubuntu/Debian 可以直接sudo apt install iozone3CentOS/RHEL 用 EPEL 源里的 iozone 也行。能用包管理器装就优先用包管理器省得自己去处理编译依赖。2.2 Windows 和 macOS 下的快速使用Windows 上没必要编译iozone 官网在 Windows 目录里提供了编译好的执行文件名字一般是wire32.exe和wire64.exe。以管理员身份打开 cmd切到解压目录直接跑wire64.exe -i 0 -i 1 -s 1G -r 4k -f C:\tmp\iozone.tmpmacOS 上源码包同样能编译进入src/current后执行make macosx再把生成的iozone复制到/usr/local/bin。如果你用 Homebrew也可以尝试brew install iozone但 Homebrew 的配方更新不算勤快真要最新版还是走源码编译。2.3 装好后先跑一条冒烟命令验证安装完之后不要直接跑大测试先来一条很小的冒烟命令确认工具本身没问题iozone -i 0 -i 1 -s 16M -r 4k -f /tmp/iozone_smoke.tmp-i 0 -i 1指定只测顺序写和顺序读-s 16M指定单文件大小-r 4k指定记录长度-f指定测试文件路径。跑完会输出 write、rewrite、read、reread 四类结果。能看到数字出来说明工具已经能正常工作接下来才进入正式的测试参数设计。3. 命令参数详解理解这些标志才能组合出有效测试3.1 常用参数速查表iozone 手册翻一遍会发现参数非常多但日常真正高频用到的就下面这些参数含义典型用法说明-a自动模式自动生成文件大小与记录长度组合-i N指定测试项可多次出现比如 -i 0 -i 1-s size测试文件大小支持 m/g 后缀比如 -s 4g-r size记录长度模拟应用单次 IO 大小比如 -r 4k-f file测试文件路径指定单个测试文件位置-F f1 f2 ...多文件路径多线程模式下每个线程一个文件-t N并发线程数和 -F 配合模拟并发压力-n size自动模式起始文件大小控制自动模式测试范围-g size自动模式最大文件大小控制自动模式测试上限-y size自动模式最小记录长度控制记录长度下界-q size自动模式最大记录长度控制记录长度上界-b file输出 Excel 兼容报告配合 -R 生成 .xls 文件-RExcel 格式输出配合 -b 使用-I使用 Direct IO绕过 page cache测真实设备能力-e每次写后 flush把脏数据强制刷下去-c每次写后关闭文件模拟真实文件开关行为-O使用 O_SYNC每次写入同步落盘结果偏保守注意-n、-g、-y、-q只有在自动模式下才有意义。手动模式直接用-s、-r指定一组值不要混着乱用否则结果容易被误解。3.2 文件大小、记录长度和缓存之间的三角关系这是 iozone 使用里面最重要的一个概念我单独拿出来说。文件大小-s决定测试能否越过页面缓存。页面缓存是会“作弊”的当测试文件小于系统可用内存时文件内容很可能完全驻留在内存里后续读写命中的全是内存速度而不是磁盘速度。做设备性能摸底时文件大小至少应该是物理内存的两倍。一台 16G 内存的机器把-s设成 32G 甚至 64G才能让大部分测试落在真实磁盘上。记录长度-r代表应用单次 IO 的大小是最能体现业务特征的一个参数。数据库的日志写一般偏小4K 到 64K文件服务器常见的块大小是 4K 到 1M大文件流媒体则偏向 1M 以上。记录长度选小了系统调用次数和锁竞争会明显拉低结果选大了又会掩盖小 IO 下的真实延迟。文件大小和记录长度要匹配。用 4K 的记录长度去测 128G 文件随机写模式会跑出天文数字一样的测试时间用 1M 记录长度去测 64M 小文件又会因为文件本身太小根本体现不出 IO 引擎的完整能力。自动模式里 iozone 会按照固定比例生成组合目的就是避免这种错配。3.3 自动模式如何控制范围别拿默认配置直接跑-a模式默认覆盖的文件大小范围很大记录长度也会从 4K 一路自增到 16M。如果你直接跑iozone -a磁盘容量有限或时间有限时一跑就是几个小时很正常。这个时候用-n、-g、-y、-q四个参数把范围收敛。iozone -a -n 1G -g 16G -y 4k -q 1M -i 0 -i 1 -i 2这条命令的含义是文件大小从 1G 开始测到 16G记录长度只测 4K 到 1M 之间的几个档位测试项目只保留顺序写、顺序读和随机读写。相比裸-a时间可控得多。我在生产环境摸底时还有一条经验先用小范围快速跑一轮找出性能拐点的大致区间再针对拐点附近的文件大小和记录长度做二次细化测试。上来就追求完整矩阵多半会浪费大把时间。4. 四个可以直接抄的实战场景4.1 场景一新到一台服务器快速做文件系统整体体检新服务器验收我通常会先对挂载目录做一次包含顺序读写和随机读写的整体摸底iozone -R -b /tmp/fs_health.xls -a -g 32G -n 1G -y 4K -q 1M -i 0 -i 1 -i 2 -c -e -f /data/iozone.test解释一下每个参数-R -b组合把结果输出成 Excel 文件方便归档和对比-a启用自动模式-g 32G把最大文件限制在 32G这台机器内存 16G文件上限是内存两倍足以压过缓存-n 1G跳过太小文件避免无意义的短测试-y 4K -q 1M控制记录长度-i 0 -i 1 -i 2只测顺序写、顺序读、随机读写-c每次写入后关闭文件-e每次写入后做 flush这两个参数能让结果更接近真实落盘性能。跑完后重点看随机读写列如果 4K 记录下的随机写明显低于预期再结合 fsync 参数做二次确认。4.2 场景二模拟数据库的小随机读写负载MySQL、PostgreSQL 这类数据库的存储访问集中在不定长页面的随机读写上4K 到 16K 的 IO 占大头。模拟时用多线程更能体现并发场景iozone -R -b /tmp/db_sim.xls -i 2 -i 8 -r 4K -s 16G -t 8 -F /testdir/db1 /testdir/db2 /testdir/db3 /testdir/db4 /testdir/db5 /testdir/db6 /testdir/db7 /testdir/db8 -c -e-i 2是随机读写-i 8是随机混合读写-r 4K固定记录长度-s 16G指定文件大小-t 8开 8 个线程-F为每个线程指定文件。这个组合模拟了 8 个会话同时对数据库文件做随机访问。如果测出来的结果连业务估算的峰值都达不到大概率要考虑换盘或调整存储方案。要提醒一句-t 8配合-F时文件数量必须和线程数一致否则会在启动阶段报错或者部分线程抢同一个文件互相干扰。4.3 场景三视频点播、大文件存储的顺序读写吞吐上限大文件顺序读写主要关心吞吐量直接指定大的记录长度避免小 IO 把结果拉低。以媒体文件场景为例iozone -R -b /tmp/media_seq.xls -i 0 -i 1 -r 1M -s 64G -f /media/iozone.test -I-r 1M模拟流媒体应用的块大小-s 64G保证文件远超内存-I开启 Direct IO 绕过 page cache。这样测出来的就是设备本身的顺序吞吐能力而不是操作系统缓存提前把数据“预热”了。如果同一块盘 Direct IO 结果比普通模式低 20% 以上说明文件系统调优空间可能很大例如预读窗口或 IO scheduler 参数需要调。4.4 场景四多线程并发读写验证文件服务上限公司要做一个小型文件共享服务我想知道这批 SATA 盘能扛住多少人同时读写直接用多文件、多线程模式压一轮iozone -R -b /tmp/share_sim.xls -i 0 -i 1 -i 2 -t 16 -s 4G -r 64K -F /share/test1 /share/test2 /share/test3 /share/test4 /share/test5 /share/test6 /share/test7 /share/test8 /share/test9 /share/test10 /share/test11 /share/test12 /share/test13 /share/test14 /share/test15 /share/test16 -c -e-s 4G是每个线程的文件大小总数据量 64G-r 64K是文件共享服务常见的 IO 块-t 16模拟 16 个客户端同时读写。结果里能看到并发场景下吞吐量是否线性扩展。如果线程数翻倍但吞吐量没涨瓶颈往往在网络或文件系统锁上而不是磁盘本身。实际命令里你要把 16 个路径全部写全用 for 循环生成路径列表更省事。真跑到一半发现某个文件路径不存在整个测试会直接中断。5. 测试结果怎么读别只盯着最后一个数字5.1 看懂控制台输出iozone 默认输出是一串很朴素的文本表。冒烟测试时你会看到类似下面这种File size set to 16384 kB Record size set to 4096 bytes Command line used: iozone -i 0 -i 1 -s 16M -r 4k -f /tmp/iozone_smoke.tmp Output is in kB/s后面跟着的表头一般是文件大小、记录大小、write、rewrite、read、reread 这几列单位是 kB/s。如果开了-b和-R这些内容还会被写进 .xls 报告里。注意单位不是 MB/s读大数字时可以先除 1024 再判断。自动模式下矩阵的行列会随着文件大小和记录长度自动展开。我习惯先把整个结果拉到 Excel 里转成带颜色的热力图颜色最深的地方就是整体性能最优的组合区域颜色断层的位置往往是需要重点关注的性能拐点。5.2 报告里需要重点关注的三类数字在多列报告里我最关注三类数字的差异和变化write 与 rewrite 的差距同一个文件重写比新写差很多说明文件系统分配新块的能力弱可能存在碎片化问题。read 与 reread 的差距首次读明显慢于重复读说明页面缓存命中起了作用如果-e已经开启 flush可能代表预读算法不够主动。随机列在记录长度变化时的曲线随机写吞吐随记录长度增加应当平缓上升如果中间出现断崖式下跌可能是文件系统锁或 IO 调度算法在特定大小下有惩罚。单看一个数字没意义看组合和趋势才有意义。这也是 iozone 相比 dd 最有价值的地方。5.3 怎么判断结果是否正常判断结果是否正常不外乎三条路。第一横向对比同型号设备。把相同命令在同样硬件上跑一遍如果新盘和旧盘差距超过 20%优先考虑固件、驱动或文件系统参数问题。第二纵向对比业务需求。数据库 4K 随机写要求每秒能完成多少次换算成 iozone 的 kB/s 以后是否达标心里要有数。第三和官方标称值比。厂商给的顺序读写数字一般是理想环境下的峰值测试条件差一点很正常。但如果只有标称值的一半不到就该检查 PCIe 通道带宽、线缆、卡口速率这些边界条件。6. 这些坑我都踩过iozone 使用中的常见误区6.1 文件大小小于内存测出的全是 page cache 的速度我刚开始用 iozone 时犯过最典型的错误拿一台 64G 内存的服务器去测一块 NVMe 盘文件大小只设了 8G。测试结果写入速度每秒 3G 以上一度以为买到了神仙盘。后来加了-I重新测实际写入只有 1.5G前者纯是页面缓存把数据吞了。所以规则很简单测设备能力时文件大小至少是物理内存的两倍测文件系统真实行为时配合-e或-I使用更有参考性。6.2 测试盘剩余空间没算清楚中途报错另一类翻车是测试盘空间不够。多线程模式下一开就是 16 个文件每个文件-s 4G一共要 64G 空间。加上文件系统本身要预留至少 5% 的块实际可用空间比df显示的还要少。跑到一半报No space left on device的情况我至少遇到过三次。建议在跑之前用df -h看一眼目标分区剩余空间然后留出至少 10% 余量。如果只是做性能测试测完立刻删掉测试文件别把几个 G 的测试文件留在生产盘上。6.3 你以为关闭了 cache实际没有-I、-O、-e 的区别-I是 Direct IO直接绕过 page cache-O是 O_SYNC让每次写入同步落盘-e是测试结束后 flush。三者都影响缓存但作用位置完全不同。实际测试时-I的数字代表“设备在不使用系统缓存时的能力”偏向硬件极限-O的数字代表“每次写入都等待落盘确认”的性能偏向数据库日志这类对持久性要求高的场景-e更像工程上的折中。搞混这三者看到两种结果不一致就开始怀疑硬件坏了其实是测的定义不一样。6.4 自动模式一跑就是几小时怎么优化iozone -a看起来简单默认范围其实非常大。文件大小从 64K 一路放大到内存大小甚至更多记录长度又从 4K 一路放到 16M再加上默认测试项多时间非常可观。解决办法是用-n -g -y -q把范围锁死。还有一个取巧的办法先用小范围跑一轮比如-n 1G -g 8G -y 4K -q 256K找到明显拐点再针对拐点周围做细分。这样比强行把完整矩阵跑完省时得多。6.5 网络文件系统上的测试注意“双层缓存”如果测试对象是 NFS、CIFS 这类网络文件系统iozone 结果很容易被两层缓存污染一层是客户端 page cache另一层是服务端 cache。要在客户端加-I或者-e尽量绕过本地缓存同时在服务端用iostat观察真实盘活。另外网络文件系统测试对网络延迟很敏感同一个网络文件系统在不同网段下测出来的数字差异很大。做对比测试时客户端和服务端的网络路径必须一致否则对比没有任何意义。iozone 这个工具刚接触时可能觉得参数多、输出乱不好上手。可一旦把文件大小、记录长度、缓存策略这几个核心概念想明白它就能变成一个非常顺手的存储摸底工具。我个人现在每次给新服务器做验收都会固定跑一遍 iozone然后把 .xls 报告存档下次遇到性能问题直接翻出来对比。最后再分享一个小习惯测试前先sync一次把系统里的脏页刷掉测试文件一定放到被测的目标文件系统上别放到系统盘测试完把报告命名带上日期、盘型、挂载方式比如fs_health_20250115_sata_ext4.xls积累半年以后回看你会感谢当时这个命名习惯。