Perf I/O aléatoires sur serveur DB avec NVMe

euh nvme et noop c le combo classique oui. t'as vérifié les firmwares de tes NVMe ? des fois y a des bugs de latence corrigés avec un firmware plus récent

t'as pas une config multi-path ou des trucs genre dm-multipath avec tes NVMe ? des fois ça met le bordel et le scheduler est pas bien appliqué

kernel version ? et t'as checké les logs dmesg pour des erreurs nvme des resets ou des trucs du genre ? des fois ça fait des pauses le temps de récupérer

firmware à jour dmesg clean pas de multipath. kernel 5.15. on a déjà regardé tout ça ça semble propre

ok. autre piste le garbage collection de tes NVMe. si la flash est trop remplie ou si le controller est saturé par le GC ça peut causer des pics. t'as quelle utilisation d'espace ? et t'as de l'over-provisioning ?

on est à 70% d'utilisation et oui il y a de l'over-provisioning. les samsung PM1733 c'est pas censé avoir ce genre de souci ils sont costauds

ptete un souci de cgroup v2 ou de répartition des ressources I/O si t'as d'autres trucs qui tournent sur la machine. même si CPU/RAM sont ok l'I/O peut être limité

tu uses `sync` ou `async` i/o pour postgres ? et tes `fsync` sont configurés comment ? une mauvaise gestion des écritures sync peut bloquer tout le pipeline

postgresql est en `fsync=on` et `synchronous_commit=on` donc oui il fait des fsync réguliers. on a besoin de la durabilité maximale. mais le problème apparaît même quand la charge est juste en lecture

alors si c'est en lecture même avec noop ça peut être le scheduler qui est pas adapté aux NVMe. pour les NVMe modernes souvent c'est même pas `noop` mais carrément laisser le kernel faire sa vie ou `none` si c'est dispo pour ta distrib

certains recommandent `none` pour les NVMe vu que les cartes gèrent leur propre queue. essaye de setter `none` si dispo. sinon mq-deadline est pas mal si t'es sur un kernel récent