Tengo un caso de prueba para journalctl donde pasa varios segundos leyendo del disco. Pero si trato de comparar varias ejecuciones del caso de prueba, encuentro que es imposiblemente rápido después de la primera ejecución. Incluso si trato de soltar cachés. ¿Por qué?
$ 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
Curiosamente time todavía muestra que hace muchas E/S a través de fallas de página (inputs ). Me doy cuenta de que si me salto el drop_caches entre ejecuciones, muestra 0 en su lugar.
Respuesta aceptada:
drop_caches solo afecta el caché del sistema de archivos del kernel. No afecta los cachés en el hardware subyacente. Aparentemente, su hardware tiene cientos de megabytes de caché (94992 * 4096 ~=400 MB). ¡Impresionante!
En mi caso es porque el kernel se está ejecutando en una VM. Entonces, el "hardware subyacente" no es un simple disco duro. Esto ilustra la configuración del disco utilizada por virt-manager .
La opción utilizada para el "modo de almacenamiento en caché" respeta los vaciados de escritura (utilizando fsync() ), pero por lo demás permite almacenar en caché escrituras y lecturas en la caché de la página del kernel del host. El "hardware subyacente" incluye efectivamente un caché de disco dentro de la RAM del host, que puede crecer hasta varios gigabytes.
libvirt / KVM llama a esto almacenamiento en caché de "reescritura".
También noté que esto acelera el reinicio de la máquina virtual.