我们有一个RHEL 5.6服务器，这里有4条到单个LUN的活动path。 我们怀疑它不能将足够的IO塞进到另一端的XIVpipe道中：
mpath0 (XXXXXXXXXXXXXXX) dm-9 IBM,2810XIV [size=1.6T][features=1 queue_if_no_path][hwhandler=0][rw] \_ round-robin 0 [prio=4][active] \_ 2:0:1:2 sdaa 65:160 [active][ready] \_ 1:0:0:2 sdc 8:32 [active][ready] \_ 1:0:1:2 sdk 8:160 [active][ready] \_ 2:0:0:2 sds 65:32 [active][ready] Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sdc 0.00 108.18 49.30 273.65 795.21 1527.35 14.38 0.49 1.51 1.16 37.50 sdk 0.00 101.00 49.70 280.44 1700.60 1525.75 19.55 0.55 1.67 1.15 38.06 sds 0.20 110.58 50.10 270.26 1287.82 1523.35 17.55 0.51 1.58 1.17 37.47 sdaa 0.00 99.60 46.31 285.23 781.64 1539.32 14.00 0.56 1.68 1.23 40.74 dm-9 0.00 0.00 195.61 1528.94 4565.27 6115.77 12.39 2.52 1.46 0.58 99.54 看起来RHEL应该能够在每条path上发送更多的IOPS（这在XIV存储子系统上是合乎需要的），但是dm-9设备上的％util（这是多path映射）在100％左右。
这是否意味着RHEL无法将任何IOPS塞入多path（因此瓶颈是RHEL）？ 我应该如何解释呢？
我们如何在个人磁盘上获得37.50，38.06，37.47，40.74的99.54％？
实验似乎证实，等待同步写入完成的内核花费的时间是针对繁忙％计算的。
所以这个特定的应用程序（带有同步审计日志的DB2）的工作量是这样做的：
到每个审计活动的审计日志。 哪个KILLEDperformance。
一切与您的DM设置似乎是好的，也iostat输出看起来完全清醒。 对于DM和花生加载XIV，1500 IOPS几乎没有。 你需要找别的地方。