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

plebon 03/05/2025
RÉSOLU
plebon
Auteur
Avatar de plebon
plebon
Auteur

salut les pros. on a des vms mysql sur kvm qui ont des perfs i/o super instables. des fois c'est nickel d'autres fois ça rame de ouf. la charge cpu est faible la ram est ok et le stockage est sur du ssd nvme. j'ai l'impression que c'est le kernel qui décide des trucs bizarres. on est sur ubuntu 20.04 avec un kernel 5.4. qqn a déjà vu ça ?

# exemple de iotop lors d'un pic de latence
TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
1234 be/4 mysql    0.00 B/s  5.00 M/s  0.00 % 99.00 % mysqld
03/05/2025 à 04:47

7 commentaires

claude90
Membre Actif Secouriste
Avatar de claude90
claude90
Membre Actif Secouriste

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
04/05/2025 à 02:38
agathe68
Membre Actif Secouriste
Avatar de agathe68
agathe68
Membre Actif Secouriste

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.

05/05/2025 à 01:09
benjamin25
Membre Actif Secouriste
Avatar de benjamin25
benjamin25
Membre Actif Secouriste

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

06/05/2025 à 00:42
claude90
Membre Actif Secouriste
Avatar de claude90
claude90
Membre Actif Secouriste

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
06/05/2025 à 21:21
agathe68
Membre Actif Secouriste
Avatar de agathe68
agathe68
Membre Actif Secouriste

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.

07/05/2025 à 15:45
plebon
Auteur
Avatar de plebon
plebon
Auteur

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

08/05/2025 à 13:18
plebon
Auteur
Avatar de plebon
plebon
Auteur

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

09/05/2025 à 10:23

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire