☰

`sync + drop_caches`がキャッシュを削除しないのはなぜですか？

tag-icon • tag-icon linux-kernel performance cache benchmark
`sync + drop_caches`がキャッシュを削除しないのはなぜですか？

テストケースがあります。journalctlディスクからの読み取りには数秒かかります。。しかし、テストケースを複数回実行してベンチマークしてみると、最初の実行以来とても速いことがわかります。キャッシュを削除しようとしても。なぜ？

$ sync && echo 1 | sudo tee /proc/sys/vm/drop_caches && /usr/bin/time journalctl -b -u dev-shm.mount
1
0.01user 0.03system 0:04.50elapsed 1%CPU (0avgtext+0avgdata 30956maxresident)k
95424inputs+0outputs (424major+665minor)pagefaults 0swaps
$ sync && echo 1 | sudo tee /proc/sys/vm/drop_caches && /usr/bin/time journalctl -b -u dev-shm.mount >/dev/null
1
0.00user 0.01system 0:00.08elapsed 26%CPU (0avgtext+0avgdata 31832maxresident)k
94992inputs+0outputs (422major+445minor)pagefaults 0swaps

興味深いことにtime、まだページフォールト（）を介して多くのIOを実行していることがわかりましたinputs。drop_caches実行間の時間をスキップするとゼロが表示されることがわかりました。

ベストアンサー1

drop_cachesカーネルファイルシステムキャッシュにのみ影響します。基本ハードウェアのキャッシュには影響しません。明らかに、ハードウェアには数百メガバイトのキャッシュ（94992 * 4096〜= 400MB）があります。素晴らしい！

私の場合、カーネルが仮想マシンで実行されていたからでした。したがって、「基本ハードウェア」は単なるハードドライブではありません。使用されるディスク設定について説明しますvirt-manager。

「キャッシュモード」オプションは書き込みフラッシュ（使用済みfsync()）を尊重しますが、それ以外の場合は、ホストコアのページキャッシュに書き込みと読み取りをキャッシュすることができます。 「基本ハードウェア」は実際にはホストRAM内のディスクキャッシュで構成されており、これは数ギガバイトまで増加する可能性があります。

libvirt/KVM はこれを「writeback」キャッシュと呼びます。

また、これはVMを再起動する速度が速くなることを示しました。

おすすめ記事