I/Oでシステムがほとんど応答しないのはなぜですか。どうすれば解決できますか?

I/Oでシステムがほとんど応答しないのはなぜですか。どうすれば解決できますか?

ハードドライブからデータを回復しています。ディスクが正常に動作しています。ファイルセットが誤って削除されました。私はphotorecを使用しており、回復したファイルを別の物理ディスクに保存しています。私のOSとExchangeはこれとは異なるデバイスにあります。

しかし、photorecを実行すると、私のシステムは本質的に利用できなくなります。 Altキーを押しながら別のウィンドウに移動(または他の方法で切り替える)すると、5〜10秒かかり、マウスが遅く不安定になり、プログラムが応答しなくなることがよくあります。操作を完了するには、出力を一時停止する必要があります(Ctrl-S、photorecがKonsole内で実行されています)。出力を再開するとすぐにシステムが遅くなり始め、1分でほとんど利用できなくなりました。

niceIOスケジューリングクラスをアイドル状態に設定し、値を19()に設定しましたが、この問題は引き続き発生します。私は32GB(!!!)のRAMを持っていますが、そのうちの1/3も使用しません。 HTを含むクアッドコアXeonがあり、CPUが使用されていません(フォトレックが一時停止されると、アイドル状態でCPU使用率がほぼ均一になります)。どちらのディスクも100 MB / s以上の継続的な転送速度を示しているため、ハードウェアのパフォーマンスは問題になりません。ただし、CPU + IO負荷が高いと、システムは以前のWindows 98システムよりも遅く反応しました。

なぜこれが起こるのか、そして解決策は何ですか?

オペレーティングシステムは、元の4.19カーネルを実行しているDebian 10(buster)です。

10個のスレッド/プロセスがフルキャパシティで実行されていても(ビデオエンコーディングや大規模プロジェクトのコンパイルには問題ありません)、システムを完全に使用でき、ロードによって通常の速度低下が発生しません。

ベストアンサー1

あなたの質問の内容のいくつかを見てみましょう。

出力を再開するとすぐにシステムが遅くなり始め、1分でほとんど利用できなくなりました。

これは、何かがしばらくバックアップされ、最終的にスループットを維持できないことを意味します。他のすべてのディスクとは別のディスクにあると言ったので、システム全体でなければなりません。

私は32GB(!!!)のRAMを持っていますが、そのうち3分の1も使用しません。

「使用」は「RSSではない」を意味すると思います。残念ながら、それほど単純ではなく、ページキャッシュも可能です。はいRSSより無料で解放する方が簡単だからといって、無料という意味ではありません。たとえば、RSSが汚れているため、最初にディスクに再フラッシュする必要があるかもしれません。この質問はその例かもしれません。 :-)

これは通常、a.) 使用中の I/O スケジューラーおよび b.) 実行中の I/O タイプの問題です。あなたの場合、これは大規模なページキャッシュ書き込みストレージになる可能性があり、通常、カーネルは一度起動した後に簡単に調整されません。これらの書き込みが別のディスクにある場合でも、ページキャッシュの形式の単一の共有状態ソースがあります。

I / O予約クラスはioniceCFQ I / Oスケジューラにのみ影響し、他のスケジューラには影響しません。しかし、CFQには、「遅延」よりも「公正性」を好むいくつかのトレードオフがあり、これは同様の状況を引き起こす可能性があります。

CFQはTID固有のモデルに基づいており、各スレッドには独自のキューがあります。その後、カーネルはこれらのキューを繰り返し、各キューからいくつかのアイテムをポップし、そのアイテムで作業し、楽しい方法で進みます。各プロセスキューの保証された作業は、CFQの「プロセス」部分です。しかし、公平性は必ずしも性能と同じではない。これは、各プロセスが通常同じ優先順位を持つことを意味します(ioniceなどの調整を除く)。

対照的に、期限は、名前が示すように、各I / O要求に遅延タイムアウトを課すことに基づいています。 TIDレベルの公平性に焦点を当てるのではなく、主に要求の欠如(作業タイプ別の変数の期限切れ)を防ぎ、各プロセスをA単位で処理するのではなく、システムを1単位として処理するなど、さまざまな問題に焦点を当てます。 「公正性」のために運営しています。

以下を試すことをお勧めします。

  1. I/O スケジューラを mq-deadline に設定します。一般に、Deadline は読み取り操作が中断されないようにするために CFQ よりも優れています。これにより、問題のディスクへのアクセスが終了したときに、これらの数秒間の一時停止を防ぐことができます。デスクトップ使用の文脈で反応を期待する場合、ほとんどの読書を実行するので、これは意味があります。
  2. io.latency私が少し扱ったcgroup v2の使用を考えてみましょう。この言葉。これはデバイス固有ではなくシステム全体に適用され、CFQを使用するよりもI / O保護と優先順位設定をより細かく制御できますionice。その後、低レイテンシのI / Oを必要とするcgroupでデスクトップを実行し、systemd-runそのような保護なしに他のcgroupでデータ回復を実行するなどの方法を使用できます。また、これにより、「停止できない」書き込み(ページキャッシュ書き込みの保存など)が発生する前に、これらの書き込みをある程度ロールバックすることができます。
  3. カーネルメモリの回収には、直接回収とkswapd回収の2種類があります。 kswapdのリサイクルは、システムメモリ使用量(キャッシュを含む!)が100%に達するのを防ぐように努力しています。これは、私たちが直接リサイクルするリサイクルの次の段階に進むのを妨げます。直接リサイクルは、アプリケーションがメモリを要求しますが、要求を満たすのに十分なメモリがない場合に発生します。これは実際に次の結果をもたらします。停止する影響を受けるアプリケーションによっては、説明した種類の遅延が発生する可能性があります。この期間中に直接リサイクルが多い場合(grep allocstall /proc/vmstatここを参照)、kswapdリサイクル範囲を下げると状況が改善するかどうかをテストする価値があります。 sysctlを使用してこれを行うことができますvm.watermark_scale_factor- 参照ここ使い方のドキュメントです。

おすすめ記事