Perf I/O dégueu sur nos DB, c'est l'ordonnanceur ?

oui c une excellente piste. sur du NVMe le mieux c presque toujours noop ou mq-deadline. CFQ est vraiment pas adapté aux disques rapides. tu peux vérifier l'ordonnanceur actuel avec cat /sys/block/nvme0n1/queue/scheduler (adapte le nom du device)

clair cfq c'est la mort pour les nvme. il essaie d'optimiser les mouvements de tête des disques rotatifs ce qui n'a aucun sens sur du flash. deadline est mieux mais noop est souvent le best pour du nvme car le stockage lui-même a son propre ordonnancement

j'ai checké c'est mq-deadline qui est actif par défaut sur ubuntu 20.04 pour mes NVMe. bon c'est déjà pas CFQ c'est ça de pris. mais est-ce que ça peut quand même causer des soucis ? j'ai l'impression que le problème c'est pas le débit max mais plutôt la latence sur des petites requêtes

mq-deadline est généralement un bon choix pour NVMe mais noop peut parfois être encore plus performant en latence surtout si tu as un bon contrôleur de stockage derrière qui gère déjà l'ordonnancement. tu peux tester de passer à noop pour voir si ça change quelque chose

echo "noop" | sudo tee /sys/block/nvme0n1/queue/scheduler

faut faire ça à chaud c'est pas persistant au reboot

avant de changer l'ordonnanceur, tu as jeté un œil aux metrics kernel level ? genre iostat -x 1 ou atop ? voir le await, svctm, %util pour le device NVMe. ça te donnera une idée si c'est bien l'I/O subsystem qui est le bottleneck et pas un autre truc genre CPU ou mémoire

oui j'ai déjà regardé iostat, le await monte en flèche quand on a les soucis, souvent à plusieurs dizaines de ms. %util est pas toujours à 100% mais le svctm est aussi élevé. je vais tenter le noop sur une de nos vms de test pour voir

si le await est haut et %util pas à fond ça pointe bien vers une latence interne au système de fichiers ou à l'ordonnanceur. noop ou même none (quand il est dispo pour certains kernels) est souvent la meilleure option avec des contrôleurs NVMe modernes qui gèrent très bien la queue des requêtes

attention none est pour les devices virtuels type loopback pas pour du nvme physique. c'est bien noop que tu dois tester

ok je confirme, noop testé sur une vm de dev, et les benchmarks préliminaires sont super prometteurs. le await a drastiquement chuté. on va pousser ça en prod sur nos DB les moins critiques en premier. un grand merci pour l'aide les gars !