解決策 1:
ディスク アクティビティを検出するためのツールを次に示します。
iotopvmstat 1iostat 1lsofstrace -e trace=open <application>strace -e trace=open -p <pid>
ps auxfで また、解釈不能なディスク スリープ状態にあるプロセスも表示されます (D ) I/O を待っているためです。
訪問者数の増加なしに負荷が 40 に達する日もあります。
バックアップを作成して、ハードドライブが徐々に故障しているかどうかを確認することもできます。ハードドライブは通常、故障する前に速度が低下し始めます。これも高負荷の理由かもしれません。
解決策 2:
top からの出力は、DBMS がほとんどの I/O 待機を経験していることを示唆しているため、データベースのチューニングの問題は明らかに調査対象の候補です。
データベース サーバーでの I/O 待機 (特に負荷の急増) は、DBMS がディスクにバインドされている (つまり、より高速なディスク サブシステムが必要) か、チューニングの問題がある可能性を示す手がかりです。おそらく、データベース サーバーのプロファイリングも検討する必要があります。つまり、データベース サーバーが何をしているか、どのクエリに時間がかかっているかを追跡します。
データベース チューニングの問題を診断するためのいくつかのスターター ポイント:-
-
最も時間がかかるクエリを見つけて、クエリ プランを調べます。あるべきではないテーブル スキャンなど、奇妙なクエリ プランがあるかどうかを確認します。データベースにインデックスを追加する必要があるかもしれません。
-
リソースの待ち時間が長いということは、一部の重要なリソース プールを拡張する必要があることを意味する場合があります。
-
長い I/O 待機時間は、より高速なディスク サブシステムが必要であることを意味する場合があります。
-
ログとデータのボリュームは別々のドライブにありますか?データベース ログには多数の小さな順次書き込みがあります (基本的に、それらはリング バッファーのように動作します)。ログと同じディスクを共有するビジーなランダム アクセス ワークロードがある場合、これはロギングのスループットに過度に影響します。データベース トランザクションをコミットするには、ログ エントリをディスクに書き出す必要があるため、システム全体にボトルネックが発生します。
一部の MySQL ストレージ エンジンはログを使用しないため、これは問題にならない可能性があることに注意してください。
脚注:キューイング システム
キューイング システム (スループットの統計モデル) は、システムが飽和状態に近づくにつれて双曲線的に遅くなります。大まかに概算すると、飽和度が 50% のシステムのキューの長さの平均は 2 です。飽和度が 90% のシステムのキューの長さは 10 で、飽和度が 99% のシステムのキューの長さは 100 です。 /P>
したがって、飽和状態に近いシステムでは、負荷の小さな変化が待機時間の大幅な変化につながる可能性があり、この場合は I/O の待機に費やされた時間として現れます。ディスク サブシステムの I/O キャパシティがほぼ飽和している場合、負荷のわずかな変化が応答時間の大幅な変化につながる可能性があります。
解決策 3:
iotop を実行 、または atop -dD 、どのプロセスが io を実行しているかを確認します。 strace を使用 詳しく見る必要がある場合。