非常に長いIO待機時間
次のシナリオは、異なるRAIDコントローラーで2回発生しました。 1つはRAID5を実行するLSIMegaRAIDで、もう1つはRAID1を実行するHP Smart ArrayE200iでした。最初、サーバーは数年間スムーズに動作します。その後、人々はパフォーマンスについて不平を言い始めます。次に、単純なディスク操作（20〜30ファイルのディレクトリでのlsなど）には最大5秒かかる可能性があるため、「アプリケーションの問題」だけではないことがわかります。重いワークロード中にvmstatが報告する内容は次のとおりです。
procs -----------memory------------ ---swap-- -----io---- -system-- ----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 8 8944 126004 20 1597500 0 0 1666 5935 282 833 10 3 0 86
1 16 8944 122276 20 1599636 0 0 612 6300 314 615 10 3 0 87
1 12 8944 123740 20 1599332 0 0 811 5103 188 794 2 2 0 96
0 19 8944 121916 20 1600808 0 0 150 7299 163 858 1 1 0 97
0 16 8944 239244 20 1612256 0 0 647 2522 156 798 0 1 0 99
0 6 8944 215308 20 1643712 0 0 3030 3060 201 956 33 5 0 62
1 13 8944 186352 20 1672540 0 0 143 6173 166 931 14 8 0 78
8 2 8944 137368 20 1710432 0 0 111 6425 171 833 48 4 0 48
1 11 8944 122500 20 1725892 0 0 306 5222 153 746 69 4 0 27
24 13 8944 128444 20 1729680 0 0 380 5210 170 4484 16 6 8 70
0 4 8944 124956 20 1731228 0 0 389 4933 272 761 4 2 0 93
0 6 8944 123004 20 1735780 0 0 15 7856 209 682 1 2 7 90
そのため、サーバーは本番環境での使用を中止し、bonnie ++でテストし、vmstatで監視します。これにより、ほぼ同じ結果が得られます。したがって、ディスクに障害があるように見えます。ただし、RAIDコントローラにクエリを実行すると、論理ドライブと物理ディスクの両方に問題がないように見えます。また、カーネルログには、ディスク操作の問題を示唆するメッセージは含まれていません。
だから私の質問は：この問題をさらにデバッグするにはどうすればよいですか？コントローラ/ディスクを交換して、その後の交換状況が改善したことを確認する必要がありますか？または、問題の正確な場所を特定するために、いくつかのコマンドを実行してその結果を調査することができますか？
書き込みキャッシュがオフになっている可能性はありますか？バッテリーが切れて、ライトバックからライトスルーに切り替わったのではないでしょうか。
バッテリーなしでキャッシュ付きの安価なハードウェアレイドの中には、デフォルトで読み取り専用のキャッシュを有効にするものがあります-書き込みキャッシュも使用するように設定し、コントローラーが設定を「失った」可能性はありますか？
その上-多分ドライブの1つが故障していますか？レイドログを見てみてください[MegaCliコマンドラインツールが役立つはずです]。