7 commentaires
hello. t'as jeté un oeil à l'i/o scheduler configuré sur tes disques nvme dans le kernel linux ? par défaut, souvent c'est mq-deadline ou none pour NVMe. si t'es sur CFQ ou BFQ, ça peut expliquer les inconstances pour des workloads random. regarde avec cat /sys/block/nvme0n1/queue/scheduler
ouais et quelle est la taille de tes queues i/o ? et c'est quel type de workload ? random read/write ? sequential ? les NVMe sont sensibles au depth de la queue. t'as benché avec fio pour avoir des métriques plus fines ?
@user_key_2 j'ai checké c'est sur mq-deadline. voici l'output
cat /sys/block/nvme0n1/queue/scheduler
[mq-deadline] kyber bfq none
@user_key_3 c'est majoritairement du random read/write, des bases de données quoi. pas encore fait de fio mais je vais m'y mettre
mq-deadline est pas mal pour NVMe. mais des fois pour certains workloads random le none scheduler (ou noop sur les anciens kernels) est encore meilleur car il laisse le hardware NVMe gérer directement l'ordonnancement. tu peux essayer de passer en none : echo none > /sys/block/nvme0n1/queue/scheduler
attention aussi à l'alignement des partitions et des blocks. si t'as une misconfiguration entre la vm et le stockage sous-jacent ça peut dégrader les perfs. et checke aussi les driver virtio-scsi ou nvme utilisés par l'hyperviseur pour la VM, des fois faut les mettre à jour
oui la queue depth est cruciale. sur esxi assure toi que ton scsi controller pour le nvme a bien la bonne config de queue depth. et côté vm la config nr_requests sous /sys/block/nvme0n1/queue/ peut jouer aussi
ok j'ai switché en none et là c'est le jour et la nuit ! les perfs sont beaucoup plus stables et je vois plus de pics de latence. je vais quand même faire des fio pour confirmer mais c'est déjà bien mieux. merci pour l'astuce de l'scheduler !
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la team j'ai des vms linux (centos 8) sur esxi avec des disques virtuels nvme et les perfs i/o sont super inconstantes. un coup j'ai des IOPS de malade et la seconde d'après ça tombe à rien. c'est du block storage dédié NVMe pas du partagé. je pensais que le NVMe serait stable à fond. des pistes ?