外部ディスクで大規模なR / W操作を実行するとシステムが遅れる
Ubuntu 18.04システムで大容量ディスクのイメージング操作を実行すると、システム全体の遅延/遅延に関する問題が発生します。システム仕様は次のとおりです。
プロセッサー：Intel Core i7（どのコアでも容量に近づくことはありません）
メモリ：12GB（容量に近づくことはありません）
システムディスク：SSD（容量に近づくことはありません）
外部ディスク：USB 3.05400および7200RPMスピニングディスク
これらの大容量ディスクイメージング操作は基本的に次のとおりです。
Nice ionice dd if=/dev/usbdisk1 of=/dev/usbdisk2
私のシステムファイルはどれもUSBディスク上にないので、理論的には、これによって多くの遅延が発生することはありません。しかし、複数のUSBディスクをイメージングしていると、システムが這うようになります。どうして？私の理解では、各ディスクには独自のIOキューがあるので、ここで何が起こっているのでしょうか？どうすれば修正できますか？
また、FWIWでは、USBディスクのイメージング速度はまったく気にしないので、システムがスムーズに動作するようにこれらの操作を遅くするソリューションは問題ありません。
どうすれば修正できますか？
ディスクイメージを書き込むときは、ddとoflag=directを使用します。 O_DIRECT書き込みは、ページキャッシュを介したデータの書き込みを回避します。注oflag=directは、良好なパフォーマンスを得るために、より大きなブロックサイズを必要とします。次に例を示します。
dd if=/dev/usbdisk1 of=/dev/usbdisk2 oflag=direct bs=32M status=progress
注：gunzipなどの別のプログラムからディスクイメージをパイプ処理したい場合があります。この場合、良好なパフォーマンスはiflag=fullblockと別のddコマンドを介したパイプにも依存します。ここでの答えに完全な例があります： なぜgunzipからddへのパイプラインが最後に遅くなるのですか？
（別の解決策は、oflag=syncの代わりにoflag=directを使用することです。これは、多くのunwrittenキャッシュページを構築しないことで機能します。 ）。
私の理解では、各ディスクには独自のIOキューがあるので、ここで何が起こっているのでしょうか。
彼らはそうします。ただし、書き込まれたデータは、IOをキューに入れる前に、まずシステムページキャッシュ（RAM内）に保存されます。
編集：
この回答が受け入れられたので、oflag=directで再テストしたと思います。これにより、「システムがクロールする」という問題が修正されます。すごい。
最も安全なオプションは、iflag=directも追加することです。このオプションがない場合でも、ddはシステムページキャッシュを介してデータを読み取っています。私に言わずにこのオプションを追加しなかったと思います。これは、特定の問題に対する1つのヒントです。
ページキャッシュを介して読み取りすぎるデータがシステムパフォーマンスに影響を与える可能性があることは明らかです。ページキャッシュを介してプッシュするデータの合計量は、システムの数倍ですRAM :-)。読み取りのパターンに応じて、カーネルは、スペースを確保するために、他のキャッシュされたデータのドロップ（またはスワップ）を開始することを決定できます。
カーネルには間違いのない先見性がありません。キャッシュからドロップされたデータを使用する必要がある場合は、ディスク/ SSDから再ロードする必要があります。これがあなたの問題ではないことを私たちに伝える証拠はのようです。
ダーティページキャッシュの制限
ただし、問題はページキャッシュを介した書き込みデータに関係している可能性があります。書き込まれていないキャッシュ、別名「ダーティ」ページキャッシュは制限されています。たとえば、ダーティページキャッシュ全体がRAMの20％に制限されていると想像できます。 （これは想像するのに便利な嘘です。真実は乱雑に書かれています ここ ）。
ddコマンドがダーティページキャッシュの最大数を埋めることができた場合、一部のデータが書き出されるまで、コマンドは強制的に「ブロック」（待機）されます。
ただし、同時に、書き込みを行う他のプログラムもブロックされます（O_DIRECTを使用しない場合）。これにより、多くのデスクトッププログラムが停止する可能性があります。彼らがログファイルを書き込もうとしたとき。別のデバイスに書き込んでいる場合でも。
全体的なダーティ制限の名前は、dirty_ratioまたはdirty_bytesです。しかし、全体像ははるかに複雑です。異なるデバイスのダーティキャッシュ間には、ある程度の調停があるはずです。開始する以前のしきい値があり、任意の1つのデバイスで使用される最大ダーティキャッシュの割合を制限しようとします。しかし、それがどれだけうまく機能するかを正確に理解するのは難しいです。
「複数のUSBディスク」をイメージングするときに問題があるとおっしゃっていると思います。たとえば、デバイスごとのしきい値は、ディスクの1つに書き込もうとしているときにうまく機能しますが、同時に複数のディスクに書き込もうとすると機能しなくなります。しかし、それは単なる考えです。何が起こっているのか正確にはわかりません。
関連：
一部のユーザーは、低速のUSBスティックに書き込むときにシステム全体の遅延を観察し、全体的なダーティ制限を下げると遅延を回避できることを発見しました。私はこれについての良い説明を知りません。
2013年に「USBスティックストール」の問題が報告されたのはなぜですか？この問題が既存の「No-I/Oダーティスロットル」コードで解決されなかったのはなぜですか？