Linux / EC2のiowait（％waがトップ）中にCPUは実際に占有されていますか？
8つのEBSボリュームと大量のディスクトラフィックを備えた8ウェイAmazonEC2インスタンス（Linux 2.6.21を実行）では、上位に高い％wa（30〜40％）、高い負荷平均（8〜9）が見られます。私の理解では、EBSボリュームからのI/Oを待機しているプロセスは、負荷平均でカウントされます（psは、負荷平均とほぼ同じ数のD状態のいくつかのプロセスを示します）。
ただし、％waの意味は明確ではありません。 CPUは実際にEBSボリュームからの応答を待って占有されていますか、それともカーネルはCPU上で別のプロセスをスケジュールしていますか？別のプロセスがスケジュールされることを期待します。しかし、なぜiowait時間が合計CPU時間のパーセンテージとして表されるのか理解できません（パーセンテージの合計が100％を超えない限り）。
EBSボリュームのI/O容量を最大にしない限り、私は関係ありませんが、CPUがI/Oを待って拘束された場合、私たちのマシンはIを使い果たす前にCPU容量を使い果たすと思います/ O容量。
CPU時間を受け取る準備ができているプロセスが少なくとも1つある場合、CPUは他のプロセスに使用できます。摩擦があります-すべてのプロセスがI/Oの完了を待機している、I/Oバウンドシステムを持つことができます。また、CPU時間を待つものがないため、CPUをスケジュール（および利用）する理由はありません。カーネルのアクティビティ...したがって、I/Owaitという用語。
vmstat 1を実行してみて、定期的に「b」列（2番目の列）に0より大きい数値があるかどうかを確認してください。もしそうなら、あなたはおそらくI/Oバウンドです。たまに見るのは大したことではありません。2〜3の範囲の数字で常に見ることは許容できますが、望ましくありません。5以上を見ると、多分忙しすぎることを意味します（ただし、それはどれだけの量によって異なります）システムが対応できるI/Oであるため、多かれ少なかれ可能性があります）。 「b」は、「実行がスケジュールされているが、I/Oの完了を待ってブロックされたプロセスの数」のように「ブロックされたプロセス」を意味します。
ファローアップ：
2.6シリーズのカーネルには重いI/Oと新しいスケジューラーに関する既知のバグがあります 。スケジューラーを変更して、影響があるかどうかを確認してください。
man vmstatは次のように述べています。「wa：IOの待機に費やされた時間。Linux2.5.41より前は、アイドルに含まれていました。」