Gros lags sur des écritures disques intenses avec db postgres

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