コピープロセスをioniceまたはniceで試してみてください。この問題は、IO が GUI と同じ優先度を取得するという事実によるもので、デスクトップの場合、認識される応答性に影響します。
現在、これについて Ubuntu のブレインストーミングがあります。
Linux は長い間、システムのすべての「汚れた」キャッシュ メモリを占有するプログラムに問題を抱えていました。何が起こっているかというと、コピー プロセスが、コピーしているファイル データで書き込みキャッシュをいっぱいにし、それを非常に高速に実行しているということです。そのため、Firefox が登場して書き込みが必要になると、最初にダーティ バッファ スペースまたはディスク キューの書き込みスロットが使用可能になるまで待機する必要があります。待機中は、コピー プロセスとカーネルの pdflush スレッドと競合し、ダーティ バッファからディスク書き込みキューにデータを移動します。
このシナリオでは、Firefox にはさらに別の問題があります。 SQLite を使用してブックマーク、履歴などを保存します。 SQLite は ACID 準拠のデータベースであり、ディスクへの書き込みがディスクにフラッシュされるトランザクション システムを使用します。 .そのため、バッファ スペースを待つ必要があるだけでなく、コピーされたファイルでいっぱいになっているディスク キューがクリアされるのを待ってから、書き込みの成功を確認する必要があります。
たくさんありました Linux のディスク キューイングおよびバッファリング システムに行われた微調整。ほぼすべてのカーネル リリースで変更があります。新しいリリースのいずれかを試してください。 sysctl 値を微調整することもできます。私はこれらが好きです:
vm.dirty_writeback_centisecs = 100
vm.dirty_expire_centisecs = 9000
vm.dirty_background_ratio = 4
vm.dirty_ratio = 80
ディスク キューのスロット数を調整することもできます。この値は /sys/block/sda/queue/nr_requests にあります . sda を代入する必要があります あなたのドライブが本当に何であれ。スロットが多いということは、IO 要求をマージする機会が増えることを意味し、CFQ IO スケジューラは優先度をより適切に処理できます。通常、スロットが少ないということは、SQLite のトランザクションのような同期 IO でディスクに書き込まれるまでの待ち時間が短くなることを意味します。スロットが少ないということは、書き込み負荷の高いプロセスが書き込み IO でキューを完全に埋め尽くす場合に、読み取り IO をディスク キューに入れるための待ち時間が短くなることも意味します。