ディスクに一括書き込みを実行するとシステムが遅くなるのはなぜですか？

これの主な理由は一般的なものです：I / OはたくさんCPU/RAMより遅い。 I / O操作を実行するプロセスがDMA（CPU負担を軽減）を使用しても、ある時点で要求が完了するのを待つ必要があるかもしれません。

最も一般的なハードドライブの状況では、ドライブに散在しているファイルにアクセスしたいアプリケーションをいくつか追加するだけで、コーヒー（紅茶など）のカップを作ることができます。 SSDを使用すると状況が良くなりますが、SSDを使用しても測定されたスループットはSATAで数百MB / sであり（回転するプラッタHDDの場合は数十MB / sと比較）、検索時間は実際には無視できます（ミリ秒と比較）。ボードの回転） - ボトルネックが発生する可能性があります。

私が理解したのは、問題はデータ転送自体ではなく、必要なオーバーヘッドです。 I / Oはカーネルによって制御されますが、ユーザースペースがなければほとんど発生しません。したがって、何が起こったのかを確認するために、I / Oを待っているアプリケーションで多くのコンテキスト切り替えがあるかもしれません（もちろん実装によって異なります）。ディスク転送の場合、複数のカーネルスレッドがリソースを配置して競合するか、忙しい待機状態になる可能性が高い（時々これは適切な戦略です）。たとえば、あるパーティションから別のパーティションにデータをコピーするには、ソースデータがどこにあるかを確認し、読み取り、ターゲットファイルシステムにスペースを割り当て、メタデータを書き、データを書き、完了するまで繰り返す最新のファイルシステムが必要であることを覚えておいてください。

ある時点でシステムがスワッピングを開始すると（通常は一般I / Oより優先順位が高い）、災害は終わります。

編集する: 一部のLinuxカーネル開発者と話をした後、状況はより明確になりました。最大の問題はI / Oスケジューラですが、どのI / Oの優先順位を決めるべきかわかりません。したがって、すべてのユーザー入力とその後のグラフィック出力はディスク/ネットワークアクティビティとキューを共有します。したがって、ページキャッシュにキャッシュされたプロセスデータ（ロードされたライブラリなど）も、ページキャッシュが他のI / Oでより効率的に使用できると判断した場合は破棄できます。これはもちろん、コードを再実行する必要がある場合は、すでに過負荷状態にある可能性があるディスクからコードを再インポートする必要があることを意味します。

つまり、Linuxカーネルに関する限り、これらの問題の多くは最近修正されました（問題は既知です）。したがって、4.4.xまたは4.5.xを例にしてみましょう。しなければならないパフォーマンスは以前よりも改善され、問題は報告されなければなりません（通常、カーネル担当者は、誰かがバグの報告とテストに役立つことを望んでいると喜んでいます）。