web-dev-qa-db-ja.com

I / Oが原因でシステムがほとんど応答しなくなるのはなぜですか？

ハードディスクからデータを回復しています。ディスクは正常に動作しています。ファイルのコレクションが誤って削除されました。私はphotorecを使用しており、回復したファイルを別の物理ディスクに保存する場所を使用しています。私のOSとスワップは、これらとは別のデバイスにあります。

ただし、photorecを実行すると、システムが本質的に使用できなくなります。別のウィンドウにalt-tab（または別の方法で切り替える）するだけで5〜10秒かかります。マウスが不安定で途切れがちで、プログラムは通常応答しません。私は何でもするために出力を一時停止しなければなりません（Ctrl-S、photorecがKonsole内で実行されています）。出力を再開するとすぐにシステムの速度が低下し始め、1分以内に再びほとんど使用できなくなります。

IOスケジューリングクラスをアイドルに、Nice値を19（）に設定しましたが、これは引き続き発生します。32GB（!!!）のRAMがあります。使用されているのは3分の1以下です。私はHTを備えたクアッドコアXeonを使用しており、CPUを使用していません（CPUの使用は、photorecがサスペンドされていると、アイドル状態でほぼフラットラインになります）。両方のディスクで100MB/sなので、ハードウェアのパフォーマンスに問題はないはずですが、CPUとIOの負荷が高い場合、システムは古いWindows 98ボックスよりも応答が遅くなります。

なぜこれが起こるのですか、そしてこれをどのように解決するのですか？

OSはDebian 10（バスター）で、ストック4.19カーネルを実行しています。

10スレッド/プロセスが完全に実行されている場合でも、システムは完全に使用できます（ビデオのエンコードや大きなプロジェクトのコンパイルは問題ありません）。

linuxdebianhard-diskperformanceio
4
jaymmer - Reinstate Monica

あなたの質問の中のいくつかを見てみましょう：

出力を再開するとすぐにシステムの速度が低下し始め、1分以内に再びほとんど使用できなくなります。

これは、ある期間にわたって何かがバックアップしており、最終的にそのスループットを維持できないことを示唆します。これは他のすべてのものとは異なるディスク上にあると述べたので、それは何かシステム全体であるはずです。

32GB（!!!）のRAMがあり、そのうち3分の1しか使用されていません。

「中古」とは、「RSSではない」という意味です。残念ながら、それほど単純ではありません-ページキャッシュareはRSSよりも簡単に解放できる可能性が高いですが、RSSが解放されているわけではありません-例として、ダーティでフラッシュが必要な場合があります最初にディスクに戻します。そして、この質問はおそらく説明です。 :-)

これは通常、a。）使用中のI/Oスケジューラー、およびb。）実行されているI/Oのタイプの問題です。あなたの場合、それはおそらくかなりの量のページキャッシュの書き戻しであり、いったん開始すると、カーネルによって簡単に調整することはできません。これらの書き込みが別のディスクにある場合でも、ページキャッシュの形式で共有状態の単一のソースがまだあります。

ioniceの意味でのI/Oスケジューリングクラスは、CFQ I/Oスケジューラにのみ影響を及ぼし、他のものには何もしません。ただし、CFQには「レイテンシ」ではなく「フェアネス」に傾くかなりの数のトレードオフがあり、このような状況になる可能性があります。

CFQは、各スレッドが独自のキューを取得するTIDごとのモデルに基づいています。これらのキューは、カーネルによってラウンドロビンで処理され、各キューからいくつかのアイテムを取り出し、それらにアクションを実行します。そして、各プロセスキューのこの保証されたアクションは、CFQの「公正な」部分です。ただし、公平性は必ずしもパフォーマンスと同じではありません。これは、各プロセスが一般に同じ優先順位を受け取ることを意味するためです（ioniceのような調整を除く）。

対照的に、締め切りは、名前が示すように、各I/O要求に待ち時間タイムアウトを課すことに基づいています。 TIDレベルでの公平性に焦点を当てるのではなく、他の多くの問題に焦点を当てています-ほとんどの場合、（操作の種類ごとの変数の有効期限による）要求の枯渇を回避し、各プロセスを1つの単位としてではなく、1つの単位としてシステムを扱うことによって「公正」のための操作。

次のことを試すことを強くお勧めします。

  1. I/Oスケジューラーをmq-deadlineに設定します。締め切りは、一般的に、CFQよりも読み取りが不足しないようにするために優れています。これにより、問題のディスクに最終的にアクセスするときに、このような数秒のストールを回避できます。デスクトップを使用する場合、ほとんどの場合、応答性が高いと予想されるときに読み取りを行うため、これは理にかなっています。
  2. Cgroup v2のio.latencyの使用を検討してください。これは this talk で少し説明しています。これはシステム全体であり、デバイスごとではなく、CFQのioniceを使用する場合よりも、I/O保護と優先順位付けをはるかに細かく制御できます。次に、低レイテンシI/Oを必要とするcgroupでデスクトップを実行し、systemd-runなどを使用して、別のcgroupでそのような保護なしにデータ復旧を実行できます。これにより、ページキャッシュライトバックなど、これらの「止められない」書き込みを、処理前に先に進めることで、いくらかダイアルバックすることができます。
  3. カーネルのメモリ再利用には、直接再利用とkswapd再利用の2つのタイプがあります。 kswapd reclaimは、システムのメモリ使用量（キャッシュを含む！）が100％になるのを回避しようとするところです。これにより、直接再生と呼ばれる再生の次の段階に進むことが回避されます。直接再利用とは、アプリケーションがメモリを要求し、その要求を満たすのに十分なだけ残っていない場合に起こることです。これにより、実際にsuspending影響を受けるアプリケーションが発生し、説明しているようなストールが発生する可能性があります。これらの期間中に多くの直接的な再利用が見られる場合（grep allocstall /proc/vmstatはこれらを示しています）、kswapd再利用の境界を低くすると状況が改善するかどうかをテストする価値があります。 vm.watermark_scale_factor sysctlを使用してこれを行うことができます-使用方法に関するドキュメントについては here を参照してください。
6
Chris Down