我们这里有一台 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%？
答案1
实验似乎证实了内核等待同步写入完成所花费的时间是计入忙百分比的。
因此，这个特定应用程序（带有同步审计日志的 DB2）的工作负载是：
- 打开（O_SYNC）
- 写（）
- 关闭（）
审计日志中记录了每项审计活动。这严重影响了性能。
答案2
您的 DM 设置似乎一切正常，iostat输出也看起来完全正常。1500 IOPS 对 DM 来说几乎不算什么，对 XIV 来说负载也微不足道。您需要另寻他处。