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 をディスク キューに入れるまでの待ち時間が短くなることも意味します。