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,
noneou
noopest souvent recommandé. tape
cat /sys/block/sdx/queue/schedulerpour voir
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
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_requestspour voir. tu peux essayer de monter ça si c'est trop bas
Membre depuis le 08/01/2020
ok j'ai checké le scheduler c
mq-deadline. on est bien en virtio-scsi. pour le
nr_requestsc'est à 256. je vais tenter de passer en
nooppour voir ce que ça donne. comment je change ça proprement sans reboot ?
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-deadlineest pas mauvais mais pour du NVMe
noopest souvent plus direct et moins gourmand en CPU
Membre depuis le 17/06/2020
pense aussi au
max_sectors_kbsi 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
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
Membre depuis le 08/01/2020
j'ai switché en
noopet 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_kbj'avais déjà touché un peu mais pas de miracle
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
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
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
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 ?