複数の仮想マシンを実行するワークステーション（Intel XeonシリーズCPU 2個と128GiB RAM）があり、結合されたCPU使用率が30％未満であるのに対し、負荷平均は20～25です。たとえば、コマンドを実行すると、tar -xzvf vm_data.tgz --directory vm4/ --strip-components=1プロセスはgzipI / Oで90％から99％の間ブロックされ、コマンドの完了に時間がかかります。
一方、ディスクへの実際の読み書きは、SATA 3.0やSSDと比較して非常に低いです（私はシングルキングストン SA400S37960GSSD）ハードウェアの制限。
gzip実際のディスクの読み取りと書き込みが非常に低いように見えますが、プロセス（私の例では）がI / Oの後に待機する原因は何ですか？私の最初の考えは、システム割り込みが非常に高く、I / Oがブロックされる理由かもしれませんが、/proc/interrupts非常に急速に増加するカウンタがないのでそうではありません。
ベストアンサー1
〜40Gを示すレポートから始めてください。無料覚えている（正確ではないことがわかっています。書くことができるメモリですが、高速で複雑な計算に40Gを使用しましょう。バッファ/キャッシュは12Gを占め、詳細は提供されていないのでダーティデータでいっぱいであることを認めます。
vm.dirty_ratioのデフォルト値は20％で、20％は40G = 8G < 12Gです。
あなたのシステムが独自に書き換えるコマンドプロセスの制限を超えて実行されているようです。つまり、問題ブロックする書いた。
次に、システムの実際の制限が何であるかを確認します。
$ sysctl -a | grep dirty
vm.dirty_ratioが実際にデフォルト値の場合は増やしてください。 （80％まで簡単に登ることができるので心配する必要はありません。私の記憶が正しい場合、Oracleは常にこの値をお勧めします。）
これにより、通常、デフォルト値が10の同伴エントリ（vm.dirty_Background_ratio）も下げることができます。低遅延システムでは、可能な限り低い値（1）を推奨し、個人的に3に設定しました。これにより、書き込みストアデーモンがより高速に動作するため、キャッシュがdirty_ratio固定制限を超える点が遅れます。
ディレクトリ構造の対応するエントリに値を反映することで一時的な変更を行うことができます/proc/sys/vm/。これらの変更を永続的に適用するには（再起動後）、編集できます。/etc/sysctl.conf
これがプロセスのブロックの直接的な原因であり、デバイスへの書き込みが遅すぎて、キャッシュの埋め込みが dirty_ratio 制限を超える理由です。 artem-s-tashkinovの回答を参照してください。