我们这里有一个RHEL5.6服务器,它有4条活动路径到一个LUN。我们怀疑它还不能在管道上塞进足够多的IOs到十四的另一端:
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%?
发布于 2011-12-02 19:41:19
实验似乎证实,内核等待同步写入完成所花费的时间被计算为繁忙的%。
因此,这个特定应用程序(带有同步审计日志的DB2)的工作负载正在执行:
对每个已审计活动的审核日志。这就扼杀了表演。
发布于 2011-12-02 19:15:11
DM设置的所有内容似乎都很好,而且iostat输出看起来完全正常。1500 IOPS几乎什么也不适合DM和花生负载的十四。你得去别的地方看看。
https://serverfault.com/questions/337111
复制相似问题