Perfs I/O sur VM avec NVMe en prod un enfer

raynaud-roland 24/08/2024
RÉSOLU
raynaud-roland
Auteur Actif
Avatar de raynaud-roland
raynaud-roland
Auteur Actif

yo la tech team

on a mis des nouvelles vm sur vsphere avec des disques nvme pour nos bases de données et c la cata niveau i/o. en dev ça marchait du tonnerre mais en prod on a une latence de dingue et des opérations qui timeout. on s'attendait à des perfs de malade avec le nvme et on est pires qu'avant. genre on voit des pics de iowait de ouf. os c du centos 7. des idées avant que je pète un câble ?


# Exemple de commande fio qu'on utilise pour tester
fio --name=randwrite --ioengine=libaio --iodepth=64 --rw=randwrite --bs=4k --direct=1 --numjobs=4 --size=1G --runtime=60 --group_reporting

le cpu et la ram sont loin d'être saturés

24/08/2024 à 23:47

7 commentaires

alice21
Membre Actif
Avatar de alice21
alice21
Membre Actif

salut

si c'est du nvme en vm t'as check ton i/o scheduler sur le linux ? par défaut c'est souvent cfq ou deadline sur centos 7 et pour le nvme c'est pas optimal. faut passer sur none ou mq-deadline si c'est un kernel récent

25/08/2024 à 21:25
wbonnin
Membre Actif
Avatar de wbonnin
wbonnin
Membre Actif

c'est ça. pour savoir lequel est actif : cat /sys/block/nvme0n1/queue/scheduler (adapte nvme0n1). pour le changer : echo "none" > /sys/block/nvme0n1/queue/scheduler. faut mettre ça dans un script au boot sinon ça saute

26/08/2024 à 19:39
raynaud-roland
Auteur Actif
Avatar de raynaud-roland
raynaud-roland
Auteur Actif

ah merde j'avais complètement zappé le scheduler. c'est bien deadline qui est actif. je vais tester avec none. j'espère que c'est ça, ça me paraît super logique

27/08/2024 à 16:32
alice21
Membre Actif
Avatar de alice21
alice21
Membre Actif

si t'es sur un kernel 4.x ou plus, mq-deadline est une bonne option aussi, c'est fait pour les devices multi-queues comme les nvme. none c'est le plus simple et souvent efficace mais mq-deadline peut avoir des avantages pour certains workloads

28/08/2024 à 14:20

attention aussi à la taille de la queue depth de tes apps ou de tes drivers. si l'app envoie des queues très profondes et que le scheduler est mal configuré ça peut empiler les requêtes et faire exploser la latence même avec du nvme

29/08/2024 à 13:09
wbonnin
Membre Actif
Avatar de wbonnin
wbonnin
Membre Actif

et aussi vérifie le paramètre vm.swappiness sur le kernel. si c'est trop haut (genre 60) et que t'as de la ram utilisée, le système peut commencer à swapper prématurément sur le disque même si t'as de la ram libre. ça tue les perfs i/o aussi

30/08/2024 à 11:12
raynaud-roland
Auteur Actif
Avatar de raynaud-roland
raynaud-roland
Auteur Actif

ok j'ai switché sur none et c'est le jour et la nuit ! les latences sont revenues à des niveaux normaux et les iops sont là. pour vm.swappiness j'étais à 30 mais je vais le baisser à 10 pour être sûr. un grand merci pour le coup de main c'était vraiment le scheduler

31/08/2024 à 10:45

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