トップコマンドからの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
ディスクアクティビティを見つけるためのいくつかのツールを次に示します。
iotopvmstat 1iostat 1lsofstrace -e trace=open <application>strace -e trace=open -p <pid>
ps auxfまた、I/Oを待機しているため、解釈不能なディスクスリープ状態にあるプロセス（D）も確認できます。
負荷は増加し、vistorの数を増やすことなく40に達することがあります。
また、バックアップを作成して、ハードドライブの動作が遅いかどうかを確認することもできます。ハードドライブは一般的に、低下する前にスローダウンし始めます。これは高負荷の原因でもあります。
上からの出力は、DBMSがほとんどのI/O待機を経験していることを示唆しているため、データベースのチューニングの問題は明らかに調査する候補です。
データベースサーバー、特にロードスパイクで待機しているI/Oは、DBMSがディスクにバインドされている（つまり、より高速なディスクサブシステムが必要である）か、チューニングに問題がある可能性があるという手がかりです。また、データベースサーバーのプロファイリングも検討する必要があります。つまり、サーバーが実行している処理と、時間のかかるクエリを追跡します。
データベースチューニングの問題を診断するためのいくつかのスターターポイント：-
最も時間がかかるクエリを見つけ、クエリプランを確認します。テーブルスキャンなど、本来あるべきでない奇妙なクエリプランがあるかどうかを確認します。おそらく、データベースにインデックスを追加する必要があります。
長いリソース待機時間は、一部の主要なリソースプールを拡張する必要があることを意味する場合があります。
I/O待機時間が長いと、より高速なディスクサブシステムが必要になる場合があります。
ログとデータのボリュームは別々のドライブにありますか？データベースログには多数の小さな順次書き込みが含まれます（基本的に、それらはリングバッファーのように動作します）。ログと同じディスクを共有しているビジーなランダムアクセスワークロードがある場合、これはログのスループットに散発的に影響します。データベーストランザクションをコミットするには、ログエントリをディスクに書き出す必要があるため、システム全体にボトルネックが発生します。
一部のMySQLストレージエンジンはログを使用しないため、これは問題ではない可能性があることに注意してください。
脚注：キューイングシステム
キューイングシステム（スループットの統計モデル）は、システムが飽和状態に近づくにつれて、双曲線的に遅くなります。高レベルの近似では、50％飽和のシステムの平均キュー長は2です。90％飽和のシステムのキュー長は10で、99％飽和のシステムのキュー長は100です。
したがって、飽和状態に近いシステムでは、負荷の小さな変化により待機時間が大幅に変化する可能性があり、この場合、I/Oの待機に費やされた時間として現れます。ディスクサブシステムのI/O容量がほぼ飽和している場合、負荷の小さな変化により、応答時間が大幅に変化する可能性があります。
iotopまたはatop -dDを実行して、どのプロセスがioを実行しているかを確認します。よく見る必要がある場合は、straceを使用してください。
どちらの画面でも、「mysqld」が原因であるように見えます。
そのデーモンが何をしているか、どのクエリが実行されているかを確認する必要があります。
負荷は増加し、vistorの数を増やすことなく40に達することがあります。
ユーザーが行っていることは、実際にそこにいる数と同じくらい重要な場合があります。フォーラムの検索などの操作は、個々のスレッドまたはスレッドのリストをロードして表示するだけではなく、より厳しいものになります。
また、専用サーバーまたはVPSで実行していますか？サービスが専用サーバー上にない場合、同じホストで実行されているアプリのアクションは、VMホストを共有するVMがI/Oリソース。
他の人が指摘したように、iotopのようなツールは、I/O応答を待機しているタスクと、そのときにアクセスしているファイルを詳しく調べるのに役立ちます。
Flipが言うように、問題はmysqlが行っていることの周りにあるようです。
現在、物理メモリの約半分がI/Oキャッシングに使用されています-フォーラムソフトウェアは通常、ディスクのホットエリアが大きく歪んでいる、少数の行を返す多くのクイッククエリを生成します。これだけ待たなければなりません。
何百万もの行を更新するクエリを実行するとき、私は今までそのようなCPU /ディスク使用量を見るだけです。
高い負荷平均は、I/Oの直接的な結果です。
Mysqlロギングをクランクアップして、そこに不正なコードがないかどうかを確認します。インデックスの変更が役立ちます。テーブルを分析すると役立つ場合があります（ただし、それほど多くはありません）。
C.
サーバーでこの非常に高いwa CPU使用率を取得しました。利用可能なメモリが不足しており、kswapd0プロセスにより、このwa CPU使用率が高くなりました。
サーバーにはスワップメモリがなかったため、次のコマンドを実行していくつか（1Gb）を作成しました（Ubuntuサーバー）。
Sudo fallocate -l 1G /swapfile
Sudo chmod 600 /swapfile
Sudo mkswap /swapfile
Sudo swapon /swapfile
wa CPU使用率は非常に低くなり、ほとんどの場合0％です。
すべてのiotopおよびその他のツールを確認した後、「dmesg」キューも確認すると、この問題の根本的な問題が発生する場合があります。私の場合は、「CIFS VFS：サーバーfile.core.windows.netが120秒以内に応答しませんでした。再接続しています...」