7 commentaires
cfq sur du nvme c'est une hérésie ! ce scheduler est fait pour les disques rotatifs où le kernel doit optimiser les déplacements de tête. sur du nvme le device est tellement rapide qu'il gère sa propre file. passe en noop ou none direct.
totalement d'acc avec user 2. les ssd et nvme ont leur propre logique de planification interne. le kernel n'a pas besoin de faire de la réordonnancement, ça ajouterait juste de la latence et de l'overhead inutile. noop ou none c'est le meilleur choix.
ok je vois le point. comment je check le scheduler actuel et comment je le change ? faut reboot la machine ?
pour voir le scheduler actuel pour un disque genre /dev/nvme0n1 :
cat /sys/block/nvme0n1/queue/scheduler
echo noop > /sys/block/nvme0n1/queue/scheduler
super j'ai vérifié c'était bien [cfq]. j'ai passé en noop sur un noeud de test. je vais monitorer mais les premiers retours sont prometteurs moins de variabilité sur les latences p99.
oui c'est la différence que tu devrais voir. moins de pics et plus de constance. si tu as des nvme qui font du mélange read/write intensif et que tu vois encore des soucis tu pourrais tester mq-deadline (qui est aussi un simple scheduler mais multi-queue) ou bfq (un peu plus complexe mais bien pour desktop/mixte) mais noop reste le plus simple et souvent le plus efficace pour du pur nvme.
merci à vous c'était bien le cfq qui foutait le bordel. noop a réglé le problème. je vais appliquer ça à tout le cluster.
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut la communauté j'ai une question sur l'optimisation I/O pour des clusters Elasticsearch. on tourne sur des instances avec des NVMe locales super rapides mais on a des pics de latence I/O de temps en temps. on est sur le scheduler par défaut (cfq). est-ce que ça vaut le coup de changer pour noop ou mq-deadline ou un autre pour les NVMe ? vous avez de l'expérience là-dessus ?