Linux fio 的随机读写测试与 IOPS / 延迟曲线绘制脚本

fio随机读写测试需加--direct=1绕过page cache、--iodepth控制队列深度、--bs=4k测IOPS，配--time_based--runtime=60和--size=10g防缓存干扰；输出曲线须用--write_iops_log与--write_lat_log生成时序日志，再清洗绘图。 fio 随机读写测试命令怎么写才不跑偏 直接用 跑随机读写，十次有八次测出来的是缓存数据或队列堆积结果，不是磁盘真实能力。关键在绕过 page cache、控制队列深度、固定 IO size 和模式。 必须加 ，否则 Linux 会把大部分 IO 拦在 page cache 里， 可能全走内存 用 模拟高并发场景，但别盲目堆高——NVMe 盘可设到 64，SATA SSD 超过 16 就容易掩盖延迟差异 是测 IOPS 的黄金值；想看吞吐就换 或 ，但两者不能混在同一轮测试比 加 ，避免因文件大小不足提前退出；同时配 （至少 2 倍于 RAM）防 swap 干扰 怎么让 fio 输出能直接画 IOPS 和延迟曲线 默认输出是人眼友好型汇总，没法直接喂给 gnuplot 或 pandas。得靠 + 后处理，但注意默认 JSON 不含逐秒明细。 加 ，生成两个日志：每秒平均 IOPS 和每秒平均延迟（单位微秒） 生成的 是纯文本，三列：时间戳、IOPS、带宽（KB/s）； 第三列是延迟（微秒），别误当成毫秒 如果要亚秒级分辨率（比如看 burst 行为），把 改成 ，但日志体积暴涨，SSD 测 60 秒可能出 600 行 别用 输出——它压根不记录时间序列，只给最终均值 gnuplot 绘制延迟曲线时常见坐标错乱 直接用 画图，经常发现 X 轴是乱序时间戳、Y 轴数值跳变巨大，其实是 log 文件里有空行或头尾非数据行。 CentOS Linux 7.9.2009 CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。 下载 先清洗： （过滤掉注释、异常大延迟） gnuplot 中 Y 轴建议用对数刻度： ，因为随机读延迟常跨 3 个数量级（几十μs 到几 ms） 如果用 插值，会平滑掉真实毛刺；真要看瞬时抖动，就用 原样连点 别漏掉单位标注： ，μ 是 ，不是 u 或 mu 多线程/多 job 下 IOPS 算术叠加为什么不准 两个 的 job 并发跑，总 IOPS 不是单个 job 的 2 倍——尤其在 SATA 盘或低队列深度下，控制器争抢会让实际吞吐塌缩。 验证方法：分别跑 、 、 ，看 IOPS 是否线性增长；若 4 线程只比 2 线程高 10%，说明瓶颈在硬件层 必须开启，否则每个 job 单独输出，sum 时容易漏算或重复算 混合读写（ ）时， 默认按字节比例混合，但 IOPS 计算仍分读/写两列，别直接加总 用 给每个 job 打标，比如 ，否则多个 job 日志混在一起根本分不清谁是谁 真正难的不是跑出数字，而是让每次测试的变量可控——同一块盘，换一个 （比如 vs ），延迟分布可能完全两样，但很多人根本没意识到自己在测引擎而非磁盘。