1. FIO入门为什么它是存储性能测试的瑞士军刀第一次接触FIO时我被它的参数数量吓到了——足足有上百个选项。但用了三年后我发现这恰恰是它的强大之处。FIO就像存储界的万能测试仪无论是企业级SSD还是家用机械硬盘都能用它测出真实性能。你可能见过很多宣称顺序读写速度500MB/s的SSD广告但实际用起来却卡顿。这是因为厂商总用最理想条件测试而FIO能模拟真实场景。比如数据库的小文件随机读写视频编辑的大文件连续写入它都能精准复现。安装FIO其实很简单。在Ubuntu上一条命令就行sudo apt-get install fio -y如果是CentOS记得先装依赖yum install libaio-devel -y我推荐从GitHub直接下载最新源码编译这样能用到所有新特性git clone https://github.com/axboe/fio.git cd fio ./configure make sudo make install2. 核心参数详解从菜鸟到高手的必经之路2.1 基础参数这些不掌握就别想测试了--rw参数决定测试模式常见的有read/write顺序读写测连续吞吐量randread/randwrite随机读写测IOPSrw/randrw混合读写模拟真实负载--bs设置块大小直接影响测试结果。4K适合测数据库场景1M适合视频处理。我曾用不同块大小测同一块SSD4K随机写性能只有1M顺序写的1/10--iodepth是队列深度相当于同时发起的IO请求数。机械硬盘建议1-4NVMe SSD可以256甚至更高。这个参数对性能影响巨大下图是我实测某企业级SSD在不同队列深度下的IOPS变化队列深度4K随机读IOPS延迟(ms)118,0000.0532280,0000.11256350,0000.732.2 高级玩法专业测试的杀手锏--ioengine选择IO引擎libaio是最常用的异步引擎。但在Windows平台测试时我发现windowsaio引擎效果更好。有个坑要注意某些引擎需要特定内核版本支持。--numjobs创建多个工作线程。测试RAID阵列时我通常设置为磁盘数量的2-4倍。但要注意CPU成为瓶颈——有次我设了128个jobs结果CPU满载导致结果失真。--runtime限制测试时长生产环境建议至少300秒。太短会有波动太长又浪费资源。我习惯先用短时间试跑确认参数无误再正式测试。3. 场景化测试实战不同业务的不同测试方法3.1 数据库OLTP场景小文件随机读写MySQL这类数据库主要看4K随机读写性能。这是我的标准测试脚本fio --namedb_test \ --filename/dev/nvme0n1 \ --ioenginelibaio \ --rwrandrw \ --rwmixread70 \ --bs4k \ --iodepth32 \ --size100G \ --runtime600 \ --numjobs4 \ --group_reporting关键点rwmixread70模拟读多写少的典型比例队列深度建议16-64太低无法发挥性能太高会增加延迟测试文件要大于缓存否则会测出错误的高性能3.2 视频处理场景大块连续读写处理8K视频需要稳定的连续吞吐量。测试脚本示例fio --namevideo_edit \ --filename/mnt/nas/video_test \ --rwwrite \ --bs1M \ --iodepth8 \ --size500G \ --runtime1200 \ --numjobs1 \ --direct1这里有几个经验实际视频编辑多是单线程大文件写入所以numjobs设为1机械硬盘阵列建议iodepth4-8SSD可以16-32一定要用direct1绕过缓存反映真实性能4. 性能调优指南从测试结果到实际优化4.1 结果解读这些数字到底什么意思看到测试输出别慌主要关注这几个指标IOPS每秒IO操作数决定随机访问性能带宽MB/s单位影响连续读写速度延迟95th或99th百分位更有参考价值去年我遇到个典型案例某云盘的IOPS测试很好但实际用起来卡顿。后来发现它的99th延迟高达800ms这就是只看平均值踩的坑。4.2 调优实战常见问题的解决方案问题1IOPS低于预期检查iodepth是否足够SSD建议至少32确认是否启用direct1否则会测试缓存速度尝试更换ioengine比如从psync改为libaio问题2延迟波动大降低numjobs避免CPU成为瓶颈检查后台进程我常用iotop监控干扰延长runtime短期波动是正常的这是我常用的监控脚本在另一个终端运行watch -n 1 iostat -xmd 1 2 | tail -n 75. 避坑指南这些年我踩过的坑第一次测试时我直接对/dev/sda进行写测试——结果把系统盘数据全清了。现在我都先用lsblk确认设备名并在非生产环境先试跑。另一个常见错误是忘记清理测试文件。有次测试完1TB文件没删除差点把磁盘撑爆。建议添加--remove_on_close1参数自动清理。最隐蔽的坑是缓存影响。某次测试结果异常好后来发现是direct参数没设置。现在我的检查清单里一定会确认这点。对于云盘测试要注意厂商的限流策略。AWS EBS就会突发性能后限速建议测试时间覆盖完整生命周期。