Eu tenho um caso de teste para journalctlonde ele gasta vários segundos lendo do disco . Mas se eu tentar comparar várias execuções do caso de teste, descubro que é incrivelmente rápido após a primeira execução. Mesmo se eu tentar descartar caches. 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, ainda o mostra fazendo muitos IO por meio de falhas de página ( inputs). Percebo que, se eu pular drop_cachesentre as execuções, ele mostrará 0.
drop_cachesafeta apenas o cache do sistema de arquivos do kernel. Não afeta os caches no hardware subjacente. Aparentemente seu hardware possui centenas de megabytes de cache (94992 * 4096 ~= 400MB). IncrÃvel!No meu caso, é porque o kernel está rodando em uma VM. Portanto, o "hardware subjacente" não é um simples disco rÃgido. Isso ilustra as configurações de disco usadas pelo
virt-manager.A opção usada para "modo de cache" respeita as liberações de gravação (usando
fsync()), mas permite o armazenamento em cache de gravações e leituras no cache de página do kernel do host. O "hardware subjacente" efetivamente inclui um cache de disco na RAM do host, podendo crescer para vários gigabytes.libvirt / KVM chama esse cache de "writeback".
Também notei que isso acelera a reinicialização da VM.