10 commentaires
hello. nvme locaux c'est bien mais quel type de nvme ? et quel est l'io scheduler actuel ? tu peux vérifier avec cat /sys/block/nvme0n1/queue/scheduler ou blockdev --report
c'est des intel p4510. l'io scheduler est none apparemment pour les nvme par défaut sur mon os. j'ai essayé noop mais pas de changement notable. je pensais que none était l'idéal pour les disques rapides comme ça
pour les nvme avec des kernels > 5.x none ou noop c'est le défaut mais pas forcément le meilleur. le mq-deadline est souvent plus performant dans ce genre de scenario avec des workloads intenses et multi-threadés
ah mq-deadline j'en ai entendu parler. j'ai les stats iostat je vois pas mal de await et svctm élevés. je vais tenter de changer pour mq-deadline sur le nvme où il y a postgres
# exemple iostat
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
nvme0n1 0.00 1000.00 0.00 4000.00 0.00 0.00 0.00 0.00 0.00 10.50 10.50 0.00 4.00 10.50 100.00
oui mq-deadline est souvent le go-to pour les nvme et les gros workloads. tu peux le changer à chaud avec echo mq-deadline | sudo tee /sys/block/nvme0n1/queue/scheduler pour tester
ok je viens de le passer à mq-deadline. je relance mes tests de charge. déjà en lecture ça semble un peu plus réactif. je vais laisser tourner pour voir si les pics d'écriture s'améliorent
l'idée derrière mq-deadline c'est qu'il est bien adapté pour les nvme qui ont déjà une très faible latence intrinsèque et gèrent leurs propres files d'attente. il se concentre sur la prévention de la famine d'i/o et le respect des délais pour les requêtes. pour postgres qui fait beaucoup d'écritures sync et de fsync c'est souvent un bon match
putain c'est le jour et la nuit ! les lags ont presque disparu je vois beaucoup moins de w_await sur iostat. c'est beaucoup plus stable même sous forte charge. impressionnant merci pour le tip
super ! n'oublie pas de rendre le changement persistant via grub ou udev rules sinon ça va revenir à none après un reboot. par ex tu peux ajouter elevator=mq-deadline dans les cmdline du kernel
ouaip je vais faire ça. encore merci beaucoup c'est une galère de moins
Laisser une réponse
Vous devez être connecté pour poster un message !
salut ! on a une instance postgres sur un vm linux qui prend cher niveau i/o. dès qu'on a des pics d'écriture ça lag de ouf genre des requêtes qui prennent des secondes. pourtant on est sur des nvme locaux. je suis sur un kernel récent (5.15) c'est ptete un souci d'io scheduler non ?