![fio 给出了一个意外的 IOPS 数字](https://linux22.com/image/793815/fio%20%E7%BB%99%E5%87%BA%E4%BA%86%E4%B8%80%E4%B8%AA%E6%84%8F%E5%A4%96%E7%9A%84%20IOPS%20%E6%95%B0%E5%AD%97.png)
在使用 fio 运行测试时,我们遇到了意外的行为。测试配置:
[global]
iodepth=64
direct=1
ioengine=libaio
group_reporting
time_based
runtime=6000
numjobs=1
rw=randrw
write_lat_log=test1
log_avg_msec=1000
write_iops_log=test1
iopsavgtime=1000
disable_slat=1
disable_clat=1
log_unix_epoch=1
[job1]
filename=/dev/sdc
bs=8k
rate_iops=10k,90k
测试配置:
- SAN 存储,iSCSI san 配置
- 运行 Vmware ESXi 的 x64 服务器,其上部署了 Linux 虚拟机。
- 服务器有 2 x 25Gb 以太网链路(4 条活动路径),ESXi 多路径配置为循环,iops=1
- 映射到虚拟机的 LUN - /dev/sdc 块设备。
我们进行了压力测试,结果导致存储性能下降。在存储正常工作时,fio 正确地生成了 90k IOPS 写入负载。在存储性能下降期间,我们观察到 fio 降低了 IOPS 水平。显然,这是由于设备队列中的操作增长而发生的。fio 减少了 IO 操作的数量以避免超过 iodepth 值。奇怪的事情发生在存储恢复后。fio 将 IOPS 增加到最大可能水平,并保持这种带宽,直到从性能下降时刻开始计算的平均 IOPS 稳定到等于 rate_iops 的值。这对我们来说是一个完全出乎意料的情况,因为 rate_iops 的描述清楚地表明,此参数将带宽限制为指定的 IOPS 数。我们设置 direct=1,文件系统/操作系统端的缓冲不应影响 IOPS。此外,我们检查了 iostat 和 esxtop,在 IOPS 开始上升之前没有看到任何排队。这证明是 fio 增加了 IOPS。演示该问题的图表 在图片上,您可以看到测试前有 90k 次写入,然后 IO 下降了一段时间,然后是稳定期,在此期间存储性能下降。然后存储恢复,您可以看到 IOPS 一段时间内上升到 ~110k,之后它最终排在 90k“正常”IOPS 水平。
我们检查了好几次,确认 IOPS 水平的增加持续时间恰好与平均 IOPS 值等于 rate_iops 值的时间一样长。我认为我们误解了 fio 配置中的某些内容。或者可能是代码中的缺陷,因为文档中没有写明 fio 可能生成高于 rate_iops 中配置的 IOPS 数。因此,任何建议或想法都将不胜感激