Linux
dm 設備 100% 使用率的含義
我們這裡有一個 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)
- 寫()
- 關閉()
到每個審計活動的審計日誌。哪個殺死了性能。
DM 設置的一切似乎都很好,
iostat
輸出看起來也完全正常。對於 DM 和 XIV 的花生負載,1500 IOPS 幾乎是零。你需要看看別的地方。