J'ai un cas de test pour journalctl où il passe plusieurs secondes à lire sur le disque. Mais si j'essaie de comparer plusieurs exécutions du cas de test, je trouve que c'est incroyablement rapide après la première exécution. Même si j'essaie de supprimer des caches. Pourquoi ?
$ 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
Intéressant time montre toujours qu'il fait beaucoup d'E/S via des défauts de page (inputs ). Je remarque que si je saute les drop_caches entre les exécutions, il affiche 0 à la place.
Réponse acceptée :
drop_caches n'affecte que le cache du système de fichiers du noyau. Cela n'affecte pas les caches du matériel sous-jacent. Apparemment, votre matériel a des centaines de mégaoctets de cache (94992 * 4096 ~=400 Mo). Génial !
Dans mon cas, c'est parce que le noyau s'exécute dans une machine virtuelle. Ainsi, le "matériel sous-jacent" n'est pas un simple disque dur. Ceci illustre les paramètres de disque utilisés par virt-manager .
L'option utilisée pour le "caching mode" respecte les vidages d'écriture (en utilisant fsync() ), mais permet sinon de mettre en cache les écritures et les lectures dans le cache de page du noyau hôte. Le "matériel sous-jacent" comprend en fait un cache disque dans la RAM de l'hôte, pouvant atteindre plusieurs gigaoctets.
libvirt / KVM appelle cette mise en cache "réécriture".
J'ai également remarqué que cela accélère le redémarrage de la VM.