誰かがIOWaitとは何かを正確に説明できますか？
Iowaitについて読んだことと同じくらい、それは私にはまだ謎です。
CPUがIO操作の完了を待機するのに費やした時間ですが、どのようなIO操作が正確に必要ですか？ IO操作が完了している間にCPUが何か他のことをして、データの処理に戻ることはできないのですか？
また、IOを正確に待機したプロセスを診断するための適切なツールは何ですか。
そして、IO待機時間を最小化する方法は何ですか？
CPUがIO操作の完了を待機するのに費やした時間ですが、どのようなIO操作が正確に必要ですか？ IO操作が完了している間にCPUが何か他のことをして、データの処理に戻ることはできませんか？
はい。オペレーティングシステムは、他のプロセスがIOでブロックされている間に実行するようにスケジュールします。ただし、そのプロセス内では、非同期IOを使用している場合を除き、IO操作が完了するまでは進行しません。
また、IOを正確に待機したプロセスを診断するための適切なツールは何ですか。
役立つと思われるいくつかのツール
iostat、ディスクのサービス時間を監視するiotop（カーネルがサポートしている場合）、IOプロセスごとの要求の内訳を監視するstrace、プロセスによって発行された実際の操作を確認する
そして、IO待機時間を最小化する方法は何ですか？
- oSがディスクブロックをメモリにキャッシュできるように、空き物理メモリがあることを確認してください
- 過度の断片化を回避するために、ファイルシステムのディスク使用率を80％未満に保ちます
- ファイルシステムを調整する
- バッテリバックアップアレイコントローラを使用する
- io操作を実行するときに適切なバッファーサイズを選択する
古い質問、最近ぶつかったが、既存の回答では不十分だと感じた。
IOWaitの定義とプロパティ
IOWait（通常、先頭に%waと表示されます）は、アイドルのサブカテゴリです（%idleは通常、定義されたサブカテゴリを除くすべてのアイドルとして表されます）。つまり、CPUは何も実行していません。したがって、CPUが処理している可能性のある別のプロセスがある限り、CPUは処理します。さらに、アイドル、ユーザー、システム、iowaitなどは、CPUに関する測定値です。つまり、iowaitは、ioを待機することによって引き起こされるアイドルと考えることができます。
正確には、iowaitは、ハードウェア割り込みの受信と処理に費やされた時間で、プロセッサーのチックの割合として表されます。通常、ソフトウェア割り込みは、%siとして個別に表示されます。
重要性と潜在的な誤解
IOWaitは、IOでボトルネックが発生しているかどうかを知ることが重要な指標になることが多いため、重要です。ただし、iowaitがなくても、必ずしもアプリケーションがnot IOでボトルネックになっているとは限りません。システムで実行されている2つのアプリケーションについて考えてみます。プログラム1のボトルネックが激しく、プログラム2がCPUのヘビーユーザーである場合、CPUの%user + %systemは100％程度である可能性があり、それに応じてiowaitは0を示します。しかし、それはプログラム2が集中的で比較的これはすべてCPUの観点からであるので、プログラム1については何も言わないようです。
IOWaitを検出するツール
Dave CheneyとXerxesの投稿を見る
ただし、単純なtopも%waに表示されます。
IOWaitの削減
また、2013年が近づいている今、他の人が言ったことに加えて、単に素晴らしいIOストレージデバイス、つまりSSDのオプションが手頃です。SSDは素晴らしいです!!!
iowait
iowaitは、プロセッサが待機している（つまり、アイドル状態で待機している時間）nothing）、その間、実際にはが未処理のディスクI/O要求でした。
これは通常、ブロックデバイス（つまり、メモリではなく物理ディスク）が遅すぎるか、単に飽和していることを意味します。
したがって、システムの負荷平均が高い場合、および検査の結果、ほとんどが実際にI/O待機が原因であることに気付いた場合、必ずしもシステムに問題があるとは限りません。これは、 machineは、I/Oバインドプロセス（つまり、何よりも多くのI/Oを実行するプロセス（非I/Oバインドシステムコール））以外は何もする必要がありません。これは、システムで実行するすべての処理が依然として非常に応答しやすいという事実からも明らかです。
ツール
sar（sysstatパッケージから、ほとんどの* nixマシンで利用可能）iostatsarface（sarのフロントエンド）
私はこのリンクからの説明と例が非常に役立つとわかりました： 正確には「iowait」とは何ですか？ 。ところで、完全を期すために、ここでのI/OはディスクI/Oを指しますが、 this other post で説明されているように、ネットワークにマウントされたディスク（nfsなど）のI/Oを含めることもできます=。
私はいくつかの重要なセクションを引用します（リンクが切れた場合）、それらのいくつかは他の人がすでに言ったことの繰り返しですが、少なくとも私にはこれらはより明確でした：
これを1文に要約すると、「iowait」はCPUがアイドル状態で、少なくとも1つのI/Oが進行中の時間の割合です。
各CPUは、user、sys、idle、iowaitの4つの状態のいずれかになります。
1つのプロセスがI/Oを待機している間に、他のプロセスを実行する準備ができているとどうなるのだろうと思っていました。以下にそれを説明します：
CPUがアイドル状態の場合、カーネルは、そのCPUから開始されたローカルディスクまたはリモートマウントディスク（NFS）に対して現在進行中のI/Oが少なくとも1つあるかどうかを判断します。ある場合は、「iowait」カウンターが1増加します。そのCPUから開始された進行中のI/Oがない場合、「アイドル」カウンターが1増加します。
そしてここに例があります：
CPU上で2つのプログラムが実行されているとしましょう。 1つは、ディスクから読み取る「dd」プログラムです。もう1つは、I/Oを行わないプログラムですが、その時間の100％を計算作業に費やしています。次に、I/Oサブシステムに問題があり、物理I/Oが完了するまでに1秒以上かかると仮定します。 I/Oの完了を待機している間、「dd」プログラムがスリープ状態になると、他のプログラムはそのCPUで実行できます。クロック割り込みが発生すると、ユーザーモードまたはシステムモードで実行されるプログラムが常に存在します。したがって、％idleと％iowaitの値は0になります。iowaitが0になったとしても、物理I/Oが完了するまでに1秒以上かかる場合は明らかにI/Oの問題がないという意味ではありません。
全文は読む価値があります。以下は このページのミラー です。
Solarisの場合、実行中の入出力操作を確認する必要がある場合は、DTraceを使用してプロセスの実行内容を調べます。 Linuxの場合、同様のプログラム systemtap があり、カーネルとプロセスの呼び出しに対して同様のレベルの公開を提供します。
DTraceを学ぶときに使用した1つの例は、cpコマンドをddコマンドと比較することでした。 ddは書き込みに対して多くの読み取りを実行しますが、cpは実行しないことがわかります。これは、主にddがデフォルトで使用するバッファサイズが原因です（覚えている場合）正しく）。
どのようなIO操作がアプリケーションとセットアップに依存します。
場合によっては、CPUが継続する必要のあるデータまたは命令を取得できない場合があるため、これは重要です。場合によっては続行できますが、実行できるアプリの種類によって異なります。大量のディスクアクセスを行うシングルスレッドアプリケーションがある場合は、待機する必要があります。
IOの時間を最小限にするには、より多くの高速なメモリを購入し、高速なディスクを取得し、使用しているディスクをデフラグします。
それがボトルネックである社内アプリケーションの場合は、大きなブロックで読み取るか、IOを非同期で実行するように最適化できるかどうかを確認します。
ps auxを使用すると、プロセスSTATを印刷できます
statがDまたはDsの場合、プロセスは無停電スリープ（通常はIO）です
プロセスが無停電スリープに入ると、runqueueのnr_iowaitが追加され、nr_iowait> 0の場合、CPUのアイドル時間がiowaitにカウントされます
vmstatは、プロセスブロックの数も表示します
r：実行時間を待っているプロセスの数。
b：割り込み不可能なスリープ状態にあるプロセスの数。
http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/