performances i/o aléatoires sur nos vms de base de données mysql

hello. pour le i/o sur nvme c'est classic. le scheduler i/o par défaut (cfq ou deadline) est pas toujours optimisé pour les ssd/nvme. essaie de passer sur mq-deadline ou noop. noop est souvent le mieux pour du nvme si le controller gère bien l'ordonnancement

echo noop > /sys/block/sdX/queue/scheduler

ouais ou ptete l'over-provisioning de tes nvme sur le host kvm. si tu as trop de vms qui partagent les mêmes nvme physiques et que la charge est déséquilibrée ça peut créer des pics de latence.

check aussi les paramètres du disque virtuel côté kvm. le cache mode. si c'est writethrough ou none ça peut avoir un impact énorme sur la latence. writeback c'est rapide mais risqué. idéalement c'est virtio-scsi avec un fsync côté guest

et ne pas oublier les flags vm.swappiness et vm.dirty_ratio. si le kernel flush trop souvent le dirty cache sur le disque ça peut créer des micro-stutter. adapte les à ton workload mysql

sysctl -w vm.swappiness=1
sysctl -w vm.dirty_ratio=10
sysctl -w vm.dirty_background_ratio=5

perso j'ai eu des soucis similaires avec le vm.compaction_proactiveness. si le kernel passe son temps à compacter la mémoire pour de l'énorme tlb ça peut impacter les perfs. ptete le désactiver.

ok le scheduler i/o en noop ça semble avoir déjà amélioré pas mal de choses. je vais aussi regarder les vm.dirty_ratio et le cache mode qemu. on n'utilise pas de swap en prod mais le swappiness peut impacter le page cache. thx pour toutes ces pistes très utiles

après quelques jours de test, le passage à noop et l'ajustement du dirty_ratio ont stabilisé les perfs. c'est plus du tout le yo-yo. nickel ! merci à tous pour l'aide