我们这里有一台RHEL 5.6服务器,有4条到单个LUN的活动路径.我们怀疑它无法将管道中的足够的IO塞进到另一端的XIV：
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/s r/s w/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应该能够在每条路径上发送更多的IOPS(这在XIV存储子系统上是可取的)但是dm-9设备上的％util(它是多路径映射)大约是100％.
这是否意味着RHEL无法将任何IOPS塞入多路径(因此瓶颈是RHEL)？我该如何解释这个？
我们如何从单个磁盘上的37.50,38.06,37.47,40.74中获得99.54％？
解决方法
实验似乎证实,内核等待同步写入完成所花费的时间是根据忙碌％计算的.
因此,此特定应用程序(具有同步审计日志的DB2)的工作负载正在执行：
>打开(O_SYNC)
>写()
> close()
每个审计活动的审计日志.哪个KILLED表现.
