Perf I/O sur VM Linux avec gros disques SSD scheduler bizarre

Posté par alexandre25 le 13/09/2025
RÉSOLU

alexandre25

Membre depuis le 08/01/2020

yo la tech, j'ai des soucis de perf I/O sur des VMs Linux (Ubuntu 20.04) qui tournent sur ESXi 7.0 avec des gros disques SSD backend (genre 2TB NVMe pass-through au host). on voit des latences I/O qui spike de façon aléatoire alors que les disques sont censés être super rapides. je suspecte un truc avec le scheduler I/O du kernel mais je suis pas sûr. des pistes ?

# fio test (exemple)
fio --name=test --ioengine=libaio --rw=randwrite --bs=4k --numjobs=4 --size=1g --runtime=60 --group_reporting

Commentaires

margaret-julien

Membre depuis le 08/02/2020

salut ! ouais sur des NVMe ou des SSD rapides, le scheduler I/O du kernel peut parfois faire plus de mal que de bien. t'as vérifié quel scheduler est actif ? pour des NVMe,

none
ou
noop
est souvent recommandé. tape
cat /sys/block/sdx/queue/scheduler
pour voir

blegrand

Membre depuis le 17/06/2020

en plus de ça, si c'est des vms, assure-toi que t'utilises bien virtio-scsi pour les contrôleurs virtuels. et que ton alignement de partition est nickel sur la vm et sur le host. un mauvais alignement ça peut vraiment tuer les perfs sur ssd

gilbert-renault

Membre depuis le 30/11/2019

fais gaffe aussi à la taille des queues I/O. le défaut est pas toujours optimal pour les NVMe.

cat /sys/block/sdX/queue/nr_requests
pour voir. tu peux essayer de monter ça si c'est trop bas

alexandre25

Membre depuis le 08/01/2020

ok j'ai checké le scheduler c

mq-deadline
. on est bien en virtio-scsi. pour le
nr_requests
c'est à 256. je vais tenter de passer en
noop
pour voir ce que ça donne. comment je change ça proprement sans reboot ?

margaret-julien

Membre depuis le 08/02/2020

pour changer à chaud :

echo noop | sudo tee /sys/block/sdX/queue/scheduler
(remplace sdX par ton device). après tu refais ton FIO test et tu compares. le
mq-deadline
est pas mauvais mais pour du NVMe
noop
est souvent plus direct et moins gourmand en CPU

blegrand

Membre depuis le 17/06/2020

pense aussi au

max_sectors_kb
si tu as des grosses I/O. la valeur par défaut est 512, tu peux essayer de la monter si tes workloads le permettent. ça réduit le nombre d'interruptions

gilbert-renault

Membre depuis le 30/11/2019

et ton kernel Linux est à jour ? des fois y a des optims I/O importantes dans les nouvelles versions. surtout avec les NVMe qui évoluent vite

alexandre25

Membre depuis le 08/01/2020

j'ai switché en

noop
et relancé le FIO. déjà ça a l'air un peu mieux les latences min/max sont plus stables. on voit moins de pics à 100ms. mais y'a encore quelques micro-spikes. on est sur un kernel 5.4.0-x, pas la dernière version mais pas non plus antique. pour le
max_sectors_kb
j'avais déjà touché un peu mais pas de miracle

margaret-julien

Membre depuis le 08/02/2020

hmm si les spikes persistent même avec

noop
, ça peut être au niveau du hyperviseur. t'as des métriques i/o côté esxi pour voir si le problème vient de la vm ou si c'est la couche en dessous qui a du mal ? des fois les partages de ressources sur le host peuvent créer des contenions inattendues

alexandre25

Membre depuis le 08/01/2020

côté ESXi tout est vert. le stockage est sous-utilisé. j'ai refait des tests et j'ai trouvé un truc bizarre : c quand une autre VM sur le même host fait de l'I/O en simultané que ça spike le plus. même si les disques sont séparés logiquement. c ptete le CPU d'I/O du host qui est un peu léger pour gérer toutes les queues

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