Ich habe einen Testfall für journalctl wo es mehrere Sekunden damit verbringt, von der Festplatte zu lesen. Aber wenn ich versuche, mehrere Durchläufe des Testfalls zu benchmarken, finde ich, dass es nach dem ersten Durchlauf unmöglich schnell ist. Auch wenn ich versuche, Caches zu löschen. Warum?
$ 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
Interessanterweise time zeigt immer noch, dass es viele IO durch Seitenfehler macht (inputs ). Das merke ich, wenn ich die drop_caches überspringe zwischen den Läufen wird stattdessen 0 angezeigt.
Akzeptierte Antwort:
drop_caches wirkt sich nur auf den Cache des Kernel-Dateisystems aus. Es wirkt sich nicht auf Caches in der zugrunde liegenden Hardware aus. Anscheinend verfügt Ihre Hardware über Hunderte von Megabyte Cache (94992 * 4096 ~=400 MB). Großartig!
In meinem Fall liegt es daran, dass der Kernel in einer VM läuft. Die „zugrunde liegende Hardware“ ist also keine einfache Festplatte. Dies veranschaulicht die Festplatteneinstellungen, die von virt-manager verwendet werden .
Die für den „Caching-Modus“ verwendete Option berücksichtigt Write-Flushes (unter Verwendung von fsync() ), erlaubt aber ansonsten das Zwischenspeichern von Schreib- und Lesevorgängen im Seiten-Cache des Host-Kernels. Die „zugrunde liegende Hardware“ umfasst effektiv einen Festplatten-Cache im RAM des Hosts, der möglicherweise auf mehrere Gigabyte anwächst.
libvirt / KVM nennt dies „Writeback“-Caching.
Mir ist auch aufgefallen, dass dies den Neustart der VM beschleunigt.