使用fio压力测试时出现超出rate_iops配置值的异常IOPS数值问题求助

我们在使用fio做存储压力测试时碰到了完全不符合预期的异常行为，想请教下大家有没有相关的排查思路或者经验。

测试用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协议
• 服务器架构：x64服务器运行VMware ESXi，其上部署了一台Linux虚拟机
• 网络与多路径：服务器配备2条25Gb以太网链路（共4条活动路径），ESXi多路径配置为轮询（round-robin），参数iops=1
• 映射设备：LUN映射到虚拟机后对应块设备/dev/sdc

问题详细描述 #

我们通过压力测试模拟存储性能降级场景，过程中的异常点如下：

• 存储正常时，fio能严格按照rate_iops=90k的配置生成写入负载，这符合预期。
• 存储性能降级期间，fio会主动降低IOPS输出，推测是设备队列操作堆积导致fio为了不超出iodepth=64的限制而降载，这部分我们能理解。

但完全超出预期的情况发生在存储恢复后：fio会把IOPS飙升到存储能承受的最大值（我们实测约110k），并一直维持这个高负载，直到从降级发生那一刻开始计算的整体平均IOPS回落到与rate_iops相等的90k时，才会恢复到正常的90k IOPS水平。

我们查了fio官方文档对rate_iops的说明，明确标注该参数用于限制IOPS带宽到指定值，但当前场景明显突破了这个限制。我们已经做了这些排查：

• 配置了direct=1，排除了文件系统/操作系统层面缓存对IOPS统计的影响
• 查看了iostat和ESXi的esxtop数据，在fio飙升IOPS的阶段没有发现设备队列堆积，确认是fio主动提升了IOPS输出

我们反复验证了多次，发现fio维持超配IOPS的时长，刚好等于让降级后的整体平均IOPS拉平到90k所需的时间。现在我们怀疑要么是对fio某个配置项的理解存在偏差，要么是fio本身存在相关逻辑bug，希望能得到大家的建议或思路。

备注：内容来源于stack exchange，提问作者it800