topコマンドのwa（I / O待ち）が大きい

私は多くの訪問者がいるフォーラムを持っていますが、ビジター数を増やすことなく負荷が40に達する日もあります。以下の出力からわかるように、待機時間は長くなっています（57％）。その理由をどうやって見つけるのですか？
サーバーソフトウェアは、Apache、MySQL、およびPHPです。

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

。

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

ディスクアクティビティを見つけるためのいくつかのツールを次に示します。

• iotop
• vmstat 1
• iostat 1
• lsof
• strace -e trace=open <application>
• strace -e trace=open -p <pid>

また、I / Oを待機しているため、ps auxfどのプロセスが解釈不能なディスクスリープ（D）にあるかを確認できます。

ビスタの数を増やすことなく、負荷が40に達するまで増加する日もあります。

バックアップを作成して、ハードドライブがゆっくりと故障しているかどうかを確認することもできます。ハードドライブは一般に、減速する前に減速し始めます。これは、高負荷を説明することもできます。

topの出力は、DBMSがほとんどのI / O待機を経験していることを示唆しているため、データベースチューニングの問題は調査すべき明らかな候補です。

データベースサーバーでのI / O待機-特に負荷の急上昇-は、DBMSがディスクにバインドされている（つまり、より高速なディスクサブシステムが必要）か、チューニングの問題がある可能性があることの手がかりです。データベースサーバーのプロファイリングも検討する必要があります。つまり、データベースサーバーが実行していることと、どのクエリに時間がかかっているかのトレースを取得する必要があります。

データベースのチューニングの問題を診断するためのいくつかのスターターポイント：-

• 最も時間がかかるクエリを見つけ、クエリプランを確認します。あるべきではないテーブルスキャンなどの奇妙なクエリプランがあるかどうかを確認します。データベースにインデックスを追加する必要があるかもしれません。

• 長いリソース待機時間は、一部の主要なリソースプールを拡張する必要があることを意味する場合があります。

• 長いI / O待機時間は、より高速なディスクサブシステムが必要なことを意味する場合があります。

• ログボリュームとデータボリュームは別々のドライブにありますか？データベースログには、多数の小さな順次書き込みがあります（基本的に、リングバッファのように動作します）。ログと同じディスクを共有するビジーランダムアクセスワークロードがある場合、これはログのスループットに不釣り合いに影響します。データベーストランザクションをコミットするには、ログエントリをディスクに書き出す必要があるため、システム全体にボトルネックが発生します。
  
  一部のMySQLストレージエンジンはログを使用しないため、これは問題にならない可能性があります。

脚注：キューイングシステム

キューイングシステム（スループットの統計モデル）は、システムが飽和に近づくにつれて双曲線的に遅くなります。高レベルの近似の場合、50％飽和のシステムの平均キュー長は2です。90％飽和のシステムのキュー長は10で、99％飽和のシステムのキュー長は100です。

したがって、飽和に近いシステムでは、負荷のわずかな変化が待機時間に大きな変化をもたらす可能性があり、この場合、I / Oの待機に費やされる時間として現れます。ディスクサブシステムのI / O容量がほぼ飽和状態にある場合、負荷のわずかな変化により、応答時間が大幅に変化する可能性があります。

iotop、またはを実行して、atop -dDioが実行しているプロセスを確認します。straceよく見る必要がある場合に使用します。

どちらの画面でも、「mysqld」が原因のように見えます。

そのデーモンが何をしているのか、どのクエリが実行されているのかを確認する必要があります。

ビスタの数を増やすことなく、負荷が40に達するまで増加する日もあります。

ユーザーがしていることは、実際にそこにいる数と同じくらい重要です。フォーラムの検索などの操作は、個々のスレッドまたはスレッドのリストをロードして表示するだけではありません。

また、専用サーバーまたはVPSで実行していますか？サービスが専用サーバー上にない場合、同じホストで実行されているアプリのアクションは、VMがホストを共有するVMがI / Oリソースの共有を奪い合うため、効果があります。

他の人が指摘したように、のようなツールiotopは、I / O応答を待っているタスクと、その時点でアクセスしているファイルをより深く調べるのに役立ちます。

Flipが言うように、問題はmysqlがやっていることの周りにあるように見えます。

現在、物理メモリの約半分がI / Oキャッシングに使用されています-フォーラムソフトウェアは通常、ディスクの非常にゆがんだホッ​​トエリアを使用して、少数の行を返す多数のクイッククエリを生成します。これだけの待ち時間。

数百万の行を更新するクエリを実行するときに、そのようなCPU /ディスクの使用量しか見ません。

高い負荷平均は、I / Oの直接的な結果です。

mysqlのログを上げて、そこに不正なコードがあるかどうかを確認します。インデックスの変更が役立ちます。テーブルの分析が役立つ場合があります（ただし、おそらくそれほどではありません）。

C.