在使用 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 数。因此，任何建议或想法都将不胜感激