11 commentaires
yo. oui carrément. pour du NVMe le scheduler I/O par défaut n'est pas optimisé. le contrôleur NVMe est déjà hyper intelligent et fait son propre ordonnancement. lui rajouter une couche logicielle avec deadline ou mq-deadline c juste de l'overhead inutile. passe en noop ou none
# vérifier le scheduler actuel
cat /sys/block/nvme0n1/queue/scheduler
# changer pour noop (temporaire)
echo noop | sudo tee /sys/block/nvme0n1/queue/scheduler
ok je vais tester ça sur une VM de pré-prod. ça se change à chaud ? et pour que ça soit persistant après reboot il faut le mettre dans grub ou un udev rule ?
oui ça se change à chaud. pour la persistance soit une règle udev soit un fichier dans /etc/default/grub pour tous les disques NVMe. genre rajouter un paramètre dans la ligne GRUB_CMDLINE_LINUX_DEFAULT style elevator=noop. attention ça s'applique à tous les disques si tu le mets dans grub
perso je préfère udev c'est plus granulaire. tu peux cibler des disques spécifiques. un fichier comme /etc/udev/rules.d/60-schedulers.rules avec ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="noop" ça marche bien
ok je vais opter pour la règle udev c'est plus propre. une fois que c'est en noop y a d'autres tunings kernel pour le NVMe ou c'est déjà pas mal ?
une fois en noop tu peux vérifier la taille de la queue I/O du device. /sys/block/nvme0n1/queue/nr_requests. des fois l'augmenter un peu peut aider si tu as des charges avec bcp d'opérations concurrentes mais pour le NVMe c'est moins critique qu'avec du SATA/SAS
et aussi la version de ton kernel. les kernels récents (5.x et plus) ont de meilleures optimisations pour le NVMe et le block layer en général. si t'es sur un vieux kernel ça peut jouer
on est en 5.15 donc ça devrait être pas mal de ce côté. je vais focus sur le scheduler et le nr_requests. j'utilise fio pour mes benchmarks. vous avez des flags particuliers à recommander pour simuler une charge réelle sur du nvme ?
pour fio sur NVMe moi j'utilise ioengine=libaio ou ioengine=io_uring (si kernel >= 5.1) et direct=1 pour bypasser le cache du filesystem. et un numjobs élevé pour bien saturer les queues. n'oublie pas le iodepth c'est crucial pour le paralellisme
fio --name=test --ioengine=io_uring --rw=randwrite --bs=4k --numjobs=16 --iodepth=64 --size=10G --direct=1 --filename=/dev/nvme0n1p1 --runtime=60
nickel les gars je vais appliquer ça sur mes tests. merci pour tous les conseils. je vous dis si ça améliore les choses
Update ! J'ai passé le scheduler en noop via une règle udev et refait mes benchmarks fio. C'est le jour et la nuit ! La latence moyenne a chuté de 50% et les percentiles élevés (99%) sont beaucoup plus stables. Le iodepth et io_uring ont aussi bien aidé. Merci à tous pour les précieuses indications, le NVMe respire enfin !
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut la team. on a des VMs critiques sous Linux (Ubuntu 20.04) sur des hyperviseurs avec du stockage NVMe local. je m'attendais à des perfs I/O de ouf mais en fait on a des latences qui montent parfois sur des charges aléatoires intenses. j'ai l'impression que le scheduler I/O par défaut (deadline ou mq-deadline je sais plus) ne gère pas super bien le NVMe. je devrais changer pour noop ?