dm 设备 100% 利用率的影响

Question

我们这里有一个 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%？

Answer 1

实验似乎证实，内核等待同步写入完成所花费的时间是根据 busy% 计算的。

因此，这个特定应用程序（带有同步审计日志的 DB2）的工作负载是：

• 打开（O_SYNC）
• 写（）
• 关闭（）

到每个审核活动的审核日志。这扼杀了性能。