10 commentaires
deadline c'est pas toujours le top pour le NVMe en fait. le kernel 4.18 est un peu vieux pour exploiter à fond les nvme modernes. tu devrais voir mq-deadline ou kyber pour les files SCSI (nvme utilise une interface scsi layer)
le none ou noop c'est si ton disque gère déjà l'ordonnancement en interne ce qui est le cas des nvme haut de gamme mais parfois le kernel peut encore faire mieux
d'acc j'essaie mq-deadline. juste pour info comment tu changes ça pour un nvme parce que c'est pas dans /sys/block/nvme0n1/queue/scheduler comme un disque normal
pour les nvme c'est un peu différent. tu cherches /sys/block/nvme0n1/queue/scheduler mais en fait tu dois changer le scsi_mod.max_sectors_kb et le elevator via les options de boot du kernel. ou plus simple pour le scheduler sur NVMe tu passes par nvme.io_poll ou nvme.io_poll_delay si tu veux tenter du polling pour la latence
sinon pour le scheduler à proprement parler c'est souvent géré au niveau de la couche block device sous sys/class/block/nvme0n1/queue/scheduler si c'est bien un block device émulé
cat /sys/block/nvme0n1/queue/scheduler
echo mq-deadline > /sys/block/nvme0n1/queue/scheduler
ça doit marcher direct si ton kernel est assez récent pour mq-deadline
ah j'ai trouvé c'est bien dans /sys/block/nvme0n1/queue/scheduler. après un echo mq-deadline, j'ai refait mes tests. c'est un peu mieux mais on est toujours pas au niveau attendu
y'a des settings au niveau du filesystem à voir ? on est en xfs
xfs c un bon choix. t'as vérifié l'alignement de tes partitions avec la taille des blocs nvme ? si c mal aligné ça peut réduire les perfs drastiquement. et la taille des inodes
sinon côté kernel y'a les valeurs nr_requests sous /sys/block/nvme0n1/queue/nr_requests. c'est le nombre de requêtes I/O en attente dans la queue. si c'est trop bas ça limite la concurrence
alignement j'ai fait ça propre à l'install. nr_requests est à 128 par défaut. c'est ptete un peu faiblard pour une db avec des milliers de transactions par sec
je tente de l'augmenter à 256 voir 512
oui nr_requests c'est une excellente piste. pour les NVMe modernes et des charges intensives tu peux monter bien plus haut que 128. parfois même 1024 ou 2048. teste par paliers pour voir le sweet spot
attention à ne pas trop monter non plus ça peut augmenter la latence moyenne si les queues deviennent trop profondes mais pour de la concurrence c'est souvent un boost
ok je suis monté à 512 et c'est beaucoup mieux là j'ai doublé mes iops ! ça doit être ça le bottleneck
je vais essayer 1024 pour voir si on peut encore gratter
excellent. n'oublie pas de rendre ça persistant avec udev rules ou dans le grub config pour pas que ça saute au reboot
# exemple udev rule
# /etc/udev/rules.d/99-nvme-scheduler.rules
ACTION=="add|change", KERNEL=="nvme0n1", ATTR{queue/scheduler}="mq-deadline", ATTR{queue/nr_requests}="1024"
thx pour le udev rule j'allais oublier. là on est à plus de 100k iops c'est top
merci à tous pour les pistes c'était bien utile
Laisser une réponse
Vous devez être connecté pour poster un message !
salut les pros du kernel
j'ai des perfs i/o catastrophiques sur un serveur avec des nvme intel dc p4510. on a une base de données qui fait beaucoup de petites écritures aléatoires et des lectures concourantes
on est sur centos 8 avec un kernel 4.18 j'ai essayé le scheduler deadline comme recommandé par pas mal de tutos pour les ssd mais c'est toujours la misère. on plafonne à 20-30k iops alors qu'on devrait être à 100k+
des idées pour optimiser ça ou un autre scheduler à tester ?