ディスクに大量のデータを書き込むと、システムが遅くなるのはなぜですか？
システムの速度低下がCPUの問題によって引き起こされるべきだと思います。ただし、書き込みはI / Oによってのみ制限されます。
データ書き込み時にハードウェア割り込みが発生しますか？もしそうなら、CPUが割り込みのためにコンテキスト切り替えを実行していた可能性があります。
答え1
これの主な理由は一般的なものです：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を例にしてみましょう。しなければならないパフォーマンスは以前よりも改善され、問題は報告されなければなりません（通常、カーネル担当者は、誰かがバグの報告とテストに役立つことを望んでいると喜んでいます）。
答え2
私の経験によると、I / Oアクティビティだけではシステムが遅くなりません。この効果は、他の操作にもI / Oが必要な場合に発生します。システムがスワッピング（強制）されて過度のI / O負荷を引き起こすと、状況が非常に悪くなる可能性があります。
I / Oに影響を与え、過度の作業の影響に影響を与える可能性がありますionice。優先順位を指定すると、idle他のジョブの待ち時間が増え続ける可能性がありますが、最小値を超えません。他の（アイドル状態ではない）ジョブに実行するI / Oジョブがある場合、I / Oジョブはすぐに中断されます。使用しているスケジューラがこれらの設定をサポートしている場合。