ここには、単一のLUNへの4つのアクティブパスを備えたRHEL5.6サーバーがあります。パイプラインからもう一方の端のXIVまで十分なIOを詰め込むことができないと思われます。
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は各パス(XIVストレージサブシステムで望ましい)にはるかに多くのIOPSを送信できるはずですが、dm-9デバイス(マルチパスマップ)の%utilは約100%になっています。
これは、RHELがIOPSをマルチパスに詰め込めないことを意味しますか(したがって、ボトルネックはRHELです)?これをどのように解釈すればよいですか?
個々のディスクの37.50、38.06、37.47、40.74から99.54%を取得するにはどうすればよいですか?
実験により、同期書き込みの完了を待機するカーネルが費やした時間がビジー%に対してカウントされることが確認されているようです。
したがって、この特定のアプリケーション(同期監査ログを持つDB2)のワークロードは次のことを行っていました。
監査されたすべてのアクティビティの監査ログに。どのKILLEDパフォーマンス。
DMの設定はすべて問題ないようですが、iostat
の出力も完全に正常に見えます。1500IOPSはDMとピーナッツはXIVにロードされます。別の場所を探す必要があります。