Performance I/O disque catastrophique sur VM Linux

ramos-cecile 03/06/2024
RÉSOLU
ramos-cecile
Auteur Actif
Avatar de ramos-cecile
ramos-cecile
Auteur Actif

bonjour les devs

on a des vm linux sur vmware qui ont des perfs i/o disque vraiment nazes. on parle de quelques dizaines de mb/s en lecture/écriture séquentielle sur des disques censés être rapides. c'est une rhel 8, on fait des tests avec fio. le même workload sur une vm avec un autre os (windows) tourne beaucoup mieux. on a l'impression que le kernel linux gère mal un truc. des idées de ce qu'on peut regarder ?

# exemple de commande fio
fio --name=test --ioengine=libaio --rw=randwrite --bs=4k --numjobs=4 --size=1G --runtime=60 --group_reporting
03/06/2024 à 01:47

8 commentaires

paulette-simon
Membre Actif Rédacteur
Avatar de paulette-simon
paulette-simon
Membre Actif Rédacteur

salut tu as quel scheduler i/o sur tes disques ? sur les vmware le default c'est souvent cfq ou deadline mais pour les vm block storage moderne genre paravirtualized c'est souvent noop ou mq-deadline qui donne les meilleures perfs. regarde avec cat /sys/block/sdX/queue/scheduler et essaie de changer

04/06/2024 à 00:13
maggie-didier
Membre Actif
Avatar de maggie-didier
maggie-didier
Membre Actif

oui le scheduler c'est la première chose. aussi, est-ce que tes vmware tools sont à jour ? et tes drivers paravirtualisés genre virtio ou vmxnet3 pour le réseau et pvscsi pour le disque sont bien utilisés ? des fois c'est les vieux drivers emulés qui plombent tout

04/06/2024 à 21:54
ramos-cecile
Auteur Actif
Avatar de ramos-cecile
ramos-cecile
Auteur Actif

le scheduler est mq-deadline. j'ai vérifié les vmware tools ils sont à jour. et on utilise bien pvscsi pour les contrôleurs disques. le problème persiste. le cpu de la vm est pas surchargé le memory est ok. juste le i/o qui est lent à mourir

05/06/2024 à 18:35
lebreton-guy
Membre Actif
Avatar de lebreton-guy
lebreton-guy
Membre Actif

y'a ptete un souci sur le hypervisor même. check le datastore où sont tes vm. s'il est partagé avec plein d'autres vm qui font beaucoup d'i/o ça peut saturer les iops ou la bande passante. et côté vmware y'a des limites d'iops configurables par vm tu as regardé si c'était pas cappé trop bas

06/06/2024 à 15:26
paulette-simon
Membre Actif Rédacteur
Avatar de paulette-simon
paulette-simon
Membre Actif Rédacteur

en plus des limites sur vmware check aussi le max_sectors_kb et nr_requests pour ton device dans /sys/block/sdX/queue. si ces valeurs sont basses ça peut limiter la profondeur de queue et donc le débit max. pour de grosses charges i/o il faut des queues profondes

07/06/2024 à 14:59
ramos-cecile
Auteur Actif
Avatar de ramos-cecile
ramos-cecile
Auteur Actif

le datastore est un nvme et les autres vm dessus sont calmes. pas de limitation iops configurée sur la vm. je vais regarder les paramètres de queue. par contre j'ai vu que sys/block/sdX/queue/rotational était à 1 alors que c'est un ssd. bizarre non ?

08/06/2024 à 10:51
maggie-didier
Membre Actif
Avatar de maggie-didier
maggie-didier
Membre Actif

ah ça c'est une très bonne piste ! si rotational est à 1 le kernel pense que c'est un disque rotatif et adapte ses heuristiques de scheduling en conséquence ce qui est catastrophique pour un ssd. essaie de le passer à 0 avec echo 0 > /sys/block/sdX/queue/rotational. ça peut faire des miracles

09/06/2024 à 10:09
ramos-cecile
Auteur Actif
Avatar de ramos-cecile
ramos-cecile
Auteur Actif

j'ai mis rotational à 0 et relancé fio. les perfs ont explosé ! on est passés de 50mb/s à plus de 500mb/s. c'était ça le problème. le kernel pensait que c'était un hdd physique. merci à tous pour l'aide c'était pas évident à trouver

10/06/2024 à 05:46

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