磁盘读写测试这块iozone是绕不开的一个老牌工具。它能在文件系统层面测出顺序读写、随机读写、重写、复读等一整套性能数据命令行参数多但逻辑清晰。这篇文章就把iozone的下载安装、核心命令参数、完整测试流程和常见坑一次性讲透适合做运维、存储选型、性能调优的朋友参考。我做性能测试这几年磁盘工具从dd一路用到fio最后发现日常最快出结论的还是iozone。一条命令能跑完大部分主流场景输出结构化数据不管给领导汇报还是自己分析都够用。今天这篇不讲废话只讲怎么用、怎么避开坑。1. 认识iozone为什么磁盘性能测试绕不开它1.1 iozone是什么能解决什么问题iozone是一个跨平台的文件系统基准测试工具最早由Don Capps在SGI工作时开发后来开源并持续维护官网在iozone.org。它做的事情核心就一件在指定目录下创建文件然后以不同的方式读写这些文件最后把每秒传输的字节数算出来。跟dd这类工具相比iozone不是测“一次性写多少最快”而是组合出几十种读写模式把场景覆盖得很全。实际工作中它能派上用场的地方不少。比如采购服务器前对比两块磁盘的真实水平新挂载的文件系统做上线前验证云主机租的云盘规格到底够不够甚至排查“磁盘变慢了”这类问题。我经常把它当成磁盘性能的体检仪先跑一遍自动模式拿到一组基准数据再针对具体场景做细化测试问题基本能定位个七八成。iozone还有一个特点它是在文件系统层面工作的不是直接往块设备上写。这意味着测试结果包含文件系统开销比如ext4和xfs在同样的磁盘上跑出来会有差异。这个特性有时候被当成缺点但反过来看它更接近业务实际——应用读写的是文件不是裸盘。1.2 iozone、dd、fio该怎么选很多人上来就问有dd和fio为什么还要用iozone。我的看法是工具各有侧重点搭配着用效率最高。dd的问题是太“单薄”它只能测顺序写或顺序读的整块搬运速度对随机小IO、混合读写这些完全没有建模能力。hdparm偏向硬件层测SATA盘还行换到文件系统场景就力不从心。fio确实强大IO模型、队列深度、延迟分布都能控制但配置复杂光命令行参数就得记半天适合做深入压测。iozone正好卡在中间它比dd专业得多比fio简单得多。一条-a参数就能把文件大小、记录大小、读写模式组合成矩阵自动跑完输出结果一眼能看懂。我的习惯是先用iozone做快速摸底发现瓶颈或者需要更细的数据时再上fio做针对性压测。1.3 下载与安装源码编译还是包管理器iozone的获取方式按平台分几种。最推荐的是从官网下载源码自己编译过程不复杂。官网是iozone.org进入Downloads页面会看到针对不同平台的源码包文件名类似iozone-3-510.tar下载后解压即可。Linux下的编译路径很清晰。解压后进入src/current目录直接执行make linux几分钟就能编出可执行文件。需要注意的是iozone编译完不需要make install生成的iozone可执行文件就在src/current目录下直接从命令行调用即可。如果需要大文件支持可以在编译前给CFLAGS加上大文件宏64位系统一般不用管但32位系统跑大文件测试时务必注意这一点。如果你的系统用包管理器那更方便。Debian/Ubuntu系直接apt install iozone3CentOS/RHEL系用yum或dnf install iozone。装好后命令行输入iozone -v能看到版本号就说明环境正常。Windows环境可以用官方提供的预编译exe或者用Cygwin自己编译不过Windows用户建议优先考虑WSL或虚拟机里测兼容性和结果稳定性会好很多。注意源码编译本身占不了多少空间但测试时文件会很大建议测试目录预留充足空间后面会详细说这个坑。2. 解剖iozone的测试模式与命令参数2.1 核心测试模式逐一拆解iozone通过-i参数指定测试模式常用的编号含义如下0 write/re-write写新文件再重写已有文件1 read/re-read读新文件再重复读2 random-read/random-write随机读写3 random-backwards-read随机反向读4 record-rewrite记录重写也就是修改已有文件的内容5 stride-read跳跃读按固定跨距跳过部分区域6 fwrite/re-fwrite使用C库fwrite函数写7 fread/re-fread使用C库fread函数读8 mixed-mindir混合读写日常最关心的是write/re-write、read/re-read、random-read/write这三组。顺序读写代表大文件拷贝、备份还原这类场景随机读写对应数据库、小文件服务等场景。我自己做存储选型时必跑的也是这三组其他模式更多是业务特殊需求才用。record-rewrite和stride-read更贴近某些特殊业务。比如数据库更新时往往是先读出旧数据再覆盖写入record-rewrite模拟的就是这类行为视频剪辑工具读取素材时经常跳跃访问大文件stride-read能测出这种模式的效率。fwrite/fread这两组用的是标准C库的带缓冲I/O跟write/read这种系统调用是两条路径前者经过用户态缓冲后者直接进入内核。对比较小的记录块两者差异可能很明显能帮我们理解应用层缓冲对性能的影响。2.2 文件大小与记录大小怎么选这是iozone使用中最重要的两个参数选错了测出来的数据没有参考价值。文件大小-s理论上要比系统内存大最好超过2倍。原因很直接Linux有page cache如果测试文件只有1GB而机器内存是16GB数据很可能一直留在缓存里后面所有读操作都变成内存读测出来的速度会高得离谱。要测真实磁盘性能就得让文件大到缓存装不下数据被迫回写磁盘、读磁盘。记录大小-r模拟的是应用程序单次I/O请求的大小。OLTP数据库大多是8K到16K的小记录视频流或大数据写入往往用1M以上的大记录。没有特殊要求时可以跑一个范围让iozone自动生成矩阵。自动模式下-n和-g控制文件大小范围-y和-q控制记录大小范围。比如-n 512m -g 16g -y 4k -q 16m表示文件大小从512MB测到16GB记录大小从4KB测到16MB每个组合都会执行一组测试。这样得到的是一个二维矩阵能清晰看出性能随参数变化的趋势。实际跑起来这个矩阵很耗时间文件越大、记录档位越多耗时越长生产环境要克制一点。2.3 常用命令参数速查表列几个我常用的参数参数含义典型用法-a自动模式自动组合文件大小和记录大小-a-i指定测试模式可用多次-i 0 -i 1 -i 2-s测试文件大小-s 16g-r记录大小-r 16k-n自动模式最小文件大小-n 512m-g自动模式最大文件大小-g 32g-y自动模式最小记录大小-y 4k-q自动模式最大记录大小-q 16m-f测试文件路径-f /data/test.ioz-F多文件路径列表与线程数配合-F file1 file2 file3-t线程数/进程数-t 8-I使用直接I/O绕过缓存-I-b测试结果写入指定二进制文件-b result.wks-R生成Excel兼容格式报表-R-C显示每个节点的测试信息-C-w测试结束后不删除文件-w-e包含fsync/flush时间-e-v查看版本-v自动模式跑起来很省心但要提醒一句如果-g设得太大、模式选择太多一次测试可能跑几个小时。生产环境时间宝贵我一般限制文件大小范围并且只选需要的模式把自动模式当成快速摸底不要指望一次跑完全部组合。手动模式下-s和-r必须显式给出这对快速定位某个场景特别有用。比如想测某块盘在16KB记录下的随机读性能只需跑-i 2 -s 32g -r 16k这类命令几分钟出结果。调优过程中我基本都用手动模式参数可控可复现性也强。提示-a和-t一起用的时候不同版本表现不一致有些版本会报错或者结果混乱。需要多线程测试时建议手动指定-s/-r/-i避免自动矩阵带来的不可控。3. 实操一次完整的磁盘性能评测流程3.1 测试前准备评测磁盘性能前先做几件事能省很多麻烦。先确认测试目录挂载在目标磁盘上别辛辛苦苦跑完发现测错盘了。用df -h查看挂载点和剩余空间mount命令可以看文件系统类型和挂载参数。我习惯在目标分区单独建一个目录比如/mnt/disk_test避免跟业务数据混在一起。然后确认空间足够。iozone测试文件大小建议超过内存2倍所以文件大小加上覆盖重写需要的空间都得考虑。比如内存16G测试文件32G那么测试分区至少要有64G以上空闲因为write模式和re-write模式实际会占用双份空间。这个坑我踩过好几次文件系统写满之后测试直接失败前面跑的数据全部作废。测试期间尽量让磁盘空闲。在线业务在跑、后台任务在整理碎片、系统在做周期清理这些都会干扰结果。我一般先top和iostat确认负载正常再开始测试。如果测试的是系统盘最好安排在业务低峰期否则测出来的数据根本没法用于横向对比。3.2 快速摸底一条命令跑出基础矩阵先跑一个自动模式的快速摸底命令如下./iozone -a -g 8g -n 512m -y 4k -q 16m -i 0 -i 1 -i 2 -f /mnt/disk_test/iozone.test -b /root/iozone_result.wks这条命令的含义自动模式文件大小从512MB测到8GB记录大小从4KB测到16MB只测写、读、随机读写三种核心模式测试文件放在指定路径结果写入iozone_result.wks。输出里会看到一张报表。每行对应一个文件大小和一个记录大小的组合列方向是速度值单位是KB/s。文件大小固定时记录大小从小变大速度通常会上升小文件小记录时速度会低一些这符合IO次数增多的客观规律。如果某个组合的数值出现断崖式下跌说明这个尺度下有瓶颈值得深挖。我第一次跑自动模式时看到满屏的数字有点懵后来摸清规律就好了。比如某一行的顺序写是800MB/s下一行的随机写只有150MB/s这个差异本身就是重要信息——说明这块存储在顺序场景和随机场景表现差距大选型时就要针对业务类型做取舍。3.3 场景化测试针对业务形态的精细命令摸底之后按业务场景细化。比如测数据库服务器磁盘重点是随机小IO./iozone -i 2 -s 32g -r 16k -I -f /mnt/disk_test/rand_16k.test这里用-s 32g确保文件超过内存-r 16k模拟数据库记录大小-I使用直接IO绕过内存缓存测的是磁盘真实随机读写能力。测视频存储或备份盘看大文件顺序吞吐./iozone -i 0 -i 1 -s 32g -r 1m -I -f /mnt/disk_test/seq_1m.test大记录大小1MB直接IO主要看顺序读写的最高吞吐。视频存储这类场景顺序读性能往往决定并发剪辑体验吞吐低于预期会直接影响使用。测多客户端场景比如NFS或并发备份用-t指定线程数./iozone -i 0 -i 1 -i 2 -s 16g -r 64k -I -t 4 -F /mnt/disk_test/f1 /mnt/disk_test/f2 /mnt/disk_test/f3 /mnt/disk_test/f4这条命令用4个进程同时写4个文件模拟并发访问。注意-F的文件数量要和-t的线程数一致否则行为不符合预期。实际并发测试有个现象线程数上去之后总吞吐不一定线性增长甚至可能下降这跟存储控制器的并发处理能力有关也是调优时要重点观察的指标。3.4 结果解读与报告输出iozone默认输出直接看就能用但为了汇报和对比建议输出Excel兼容格式。用-R参数或加-b参数结果可以用Excel或LibreOffice打开。如果要做成趋势图把wks文件导入绘图工具即可。多跑几轮取稳定值。很多磁盘测试第一次跑会偏高因为文件系统元数据可能还没分配完第二次、第三次数据更接近真实。我一般跑3轮取中间值或最小值作为结论最大值往往有缓存或其他因素干扰。另外建议测试结束保留一个结果文件归档方便后续做性能趋势对比。磁盘性能下降是渐进过程没有历史数据很难判断“变慢了多少”。我维护的服务器都会给每台建立一份iozone基线每次出问题先跑一次和基线对比是健康劣化还是配置变更导致的性能变化一眼就能看出来。4. 常见问题与避坑指南4.1 测试结果高到离谱多半是缓存效应用iozone最常见的问题是写测试轻松跑出几GB/s比理论带宽还高很大概率是没绕过page cache。Linux默认策略是尽量利用内存缓存写数据write()返回时数据可能还在内存里系统在后台慢慢落盘。解决手段有三个。第一用-I参数走直接IO数据不经过page cache测的就是真实设备性能。第二把测试文件设置成内存的2倍以上缓存装不下部分数据必然落盘。第三测试前清一次缓存echo 3 /proc/sys/vm/drop_caches再开始测。顺序读测试相对不容易被缓存干扰因为文件已经存在读数据如果全在缓存里也会虚高。所以最好统一用-I测读部分这样对比性更强。做对比验证时所有场景要保持一致的参数否则数据没有可比性。我这里说的对比指的是同盘不同时间比或者不同盘之间比参数不一致就没有意义。4.2 常见报错与排查手册我整理了几个高频报错做成一个速查表报错信息常见原因解决办法Permission denied测试目录无写权限检查属主或加sudo运行Could not open file / File size too large空间不足或文件大小限制确认剩余空间ulimit -f放开-a与-t同时使用报错版本不允许自动模式与多线程混用手动指定-s、-r、-i再配-tOffset too large32位系统大文件溢出编译时加-D_LARGEFILE64_SOURCE测试中途被kill文件太大、写盘太慢被系统杀掉减小-s或-g拆分多轮测试Permission denied这个报错最容易忽视很多系统默认/tmp有特殊权限管理往不能写的位置放测试文件就会这样。文件大小限制这个很多环境里ulimit -f是unlimited但在某些加固过的系统上会被限制提前检查一下能省很多时间。32位系统那个报错现在新机器基本遇不到但搞嵌入式或者老服务器时会踩到。解决办法是在src/current目录下先执行make clean然后带上宏重新编译。提示iozone默认测试完成后会删除测试文件若想保留文件做复测或分析记得加-w参数。保留文件还有一个好处可以直接对同一个文件反复跑读测试排除创建文件带来的干扰。4.3 实测心得与性能调优建议跑了很多次iozone后我有几个经验供参考。测试前看一眼文件系统类型和挂载参数。ext4的dataordered和xfs的默认配置在随机写场景表现会有差别挂载时加了barrier或sync这类选项性能会明显下降。如果测试目的是磁盘本身建议统一用默认挂载参数避免文件系统因素干扰。对SSD和HDD要区分解读结果。HDD的顺序读写在百兆到两百兆级别随机小IO比较惨只有几兆级别SSD随机小IO能跑到几百兆顺序读写如果走NVMe能到几GB/s。如果HDD随机测试数值很低不用惊讶这是物理规律。反过来如果用SSD测出随机写只有几十兆那就得怀疑固件策略或者队列深度设置有问题。多次测试取稳定值别拿最高值到处宣传。磁盘刚格式化完跑出来的数据往往比较好看越往后越接近真实水平。我用iozone给几十台机器做过验收统一的做法是跑三轮取中位数低于厂商标称的80%就认为不合格。测试文件尽量放在数据区的最深处。很多存储系统前端是缓存层尾端才是真实介质文件如果落在缓存覆盖区测的是缓存性能。这个问题在使用存储阵列时特别明显建议结合厂商文档确认。另外ZFS、Btrfs这类带校验和快照的复杂文件系统会带来额外地CPU和IO开销测试结果比ext4偏低是正常的。最后多说一句iozone虽然好用也别把它当成万能钥匙。磁盘层、文件系统层、应用层是三层不同的东西iozone测的是文件系统层的表现。需要精确到块设备或队列深度的性能还是得上fio这类工具。我个人的习惯是每台新服务器到手先跑一轮iozone归档隔半年再跑一轮对比磁盘状态和历史趋势一目了然。测试这东西最重要的不是命令记得多熟而是每次测试条件统一数据才有可比性。这些经验都是我踩坑换来的希望看这篇文章的人能少走点弯路。