ハードディスクからデータを回復しています。ディスクは正常に動作しています。ファイルのコレクションが誤って削除されました。私は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スレッド/プロセスが完全に実行されている場合でも、システムは完全に使用できます(ビデオのエンコードや大きなプロジェクトのコンパイルは問題ありません)。
あなたの質問の中のいくつかを見てみましょう:
出力を再開するとすぐにシステムの速度が低下し始め、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つの単位としてシステムを扱うことによって「公正」のための操作。
次のことを試すことを強くお勧めします。
io.latency
の使用を検討してください。これは this talk で少し説明しています。これはシステム全体であり、デバイスごとではなく、CFQのionice
を使用する場合よりも、I/O保護と優先順位付けをはるかに細かく制御できます。次に、低レイテンシI/Oを必要とするcgroupでデスクトップを実行し、systemd-run
などを使用して、別のcgroupでそのような保護なしにデータ復旧を実行できます。これにより、ページキャッシュライトバックなど、これらの「止められない」書き込みを、処理前に先に進めることで、いくらかダイアルバックすることができます。grep allocstall /proc/vmstat
はこれらを示しています)、kswapd再利用の境界を低くすると状況が改善するかどうかをテストする価値があります。 vm.watermark_scale_factor
sysctlを使用してこれを行うことができます-使用方法に関するドキュメントについては here を参照してください。