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

Question

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

claude90 · Answer

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

agathe68 · Answer

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.

benjamin25 · Answer

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

claude90 · Answer

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

agathe68 · Answer

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.

plebon · Answer

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

plebon · Answer

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

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

Commentaires

Laisser une réponse

Déployer, manipuler et sécuriser un serveur Registry Docker privé

Améliorer le modèle DevOps : les performances (DORA)

Guide pour configurer de votre environnement GoLang

Rejoindre la communauté