10 commentaires
Le vfs_cache_pressure aide à garder les dentry/inode, mais si ton souci est lié aux données de la base, c'est peut-être plutôt le dirty_ratio qui est trop haut.
Tu penses qu'il faudrait réduire vm.dirty_ratio pour forcer un flush plus régulier plutôt qu'un gros blocage ?
Exactement. Si ton dirty_ratio est à 20%, le kernel attend trop longtemps avant de flusher. Essaie de descendre à 5% ou 10% pour lisser l'IO sur le temps.
J'ai ajusté à 5% et 10%. Les pics d'iowait semblent moins violents, mais la latence disque monte un peu en continu.
C'est le compromis habituel. As-tu regardé du côté de fio pour stresser ton contrôleur et voir où se situe le goulot d'étranglement réel ?
Vérifie aussi le scheduler disque. Si tu es sur du SSD NVMe, passe en none au lieu de mq-deadline.
Je suis sur du mq-deadline actuellement. Je vais passer en none ce soir pour voir l'impact sur le throughput.
Merci pour les conseils. Le tuning combiné du dirty_ratio et du scheduler none a stabilisé mes backups. Très efficace.
Laisser une réponse
Vous devez être connecté pour poster un message !
Mon serveur de base de données subit des épisodes de
iowaittrès élevés lors des backups. J'ai l'impression que le kernel purge agressivement le cache page, ce qui tue les performances en lecture.J'ai testé
vm.swappinessà 10, mais ça ne suffit pas. Quelqu'un a des retours sur le tuning devm.vfs_cache_pressure?