perf i/o nvme pas ouf sur prod
Commentaires
hello. avec du nvme il faut absolument que l'i/o scheduler soit sur
none. pas
mq-deadlineni
noop. les nvme gèrent leur propre ordonnancement c'est mieux. tu as vérifié ça ?
et aussi les options de mount de ton filesystem. genre
noatimec'est un classique pour éviter des writes inutiles sur chaque read. et si c'est du xfs/ext4, la taille des blocs ?
discardpour le trim si tu veux mais attention ça peut aussi impacter les perfs en charge
une fois le scheduler bien configuré, benchmarke avec
fiopour isoler le problème. sans ça c difficile de dire si ça vient de la db ou de l'infra disque. un simple
fio --name=test --ioengine=libaio --iodepth=64 --rw=randwrite --bs=4k --size=1G --numjobs=1 --direct=1 --filename=/dev/nvme0n1peut donner un bon aperçu
merci pour les retours. alors pour le scheduler :
# cat /sys/block/nvme0n1/queue/scheduler
[mq-deadline] kyber bfq none
mq-deadlinepar défaut. pour les options de mount j'ai bien
noatime. j'ai pas mis
discard. je vais essayer de changer le scheduler
oui clairement
mq-deadlinec'est pas fait pour du nvme. c'est pour les disques rotatifs ou certains sdd sata. pour du nvme il faut le mettre sur
noneça laisse le hardware nvme gérer l'ordonnancement. tu peux le changer à chaud avec
echo none > /sys/block/nvme0n1/queue/schedulermais pour que ça survive au reboot il faut un udev rule ou le passer en paramètre kernel
ok je viens de passer le scheduler en
nonesur un noeud de test. je relance mes tests db et
fio.
# echo none > /sys/block/nvme0n1/queue/scheduler
# cat /sys/block/nvme0n1/queue/scheduler
mq-deadline kyber bfq [none]
fio randwriteest deux fois plus rapide en iops. c'est bon signe !
top ! après avoir changé le scheduler tu peux aussi regarder
nr_requests(le nombre de requêtes i/o en attente) et
read_ahead_kbdans le même répertoire
/sys/block/nvme0n1/queue/. des fois les valeurs par défaut sont pas optimales pour des gros workloads
et n'oublie pas la config de cassandra aussi. genre
commitlog_sync_period_in_msou
fsyncpour les data directories. une db mal tunée peut annuler les gains du disque. mais le scheduler est une excellente première étape
c'était bien ça le scheduler. après le passage à
noneet quelques réglages
read_ahead_kb(passé à 128k) et
nr_requests(passé à 1024), j'ai vu une amélioration notable. les latences ont baissé drastiquement. on va déployer ça partout. thx pour l'aide précieuse !
nickel, good job ! les schedulers c'est souvent un piège sur les nvme
Laisser une réponse
Vous devez être connecté pour poster un message !
Rejoindre la communauté
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
margot30
Membre depuis le 05/11/2023actif
salut la team. j'ai un souci de perf i/o sur nos serveurs de prod qui ont des nvme. on s'attendait à des millions d'iops mais on est loin du compte sur un workload db (cassandra). on voit des latences par moment et la bande passante est pas maxée. on a bien des nvme samsung pm9a3. la machine est sous ubuntu 22.04. je pense à un truc au niveau du kernel ou des drivers. des idées ?