Performances I/O sur VM Linux trop lentes
Posté par
zblot
le 24/11/2025
RÉSOLU
Membre depuis le 02/09/2024
Salut à tous ! J'ai une VM CentOS 7 sur AWS (type m5.large avec EBS gp2) qui sert de base de données (PostgreSQL) et les perfs I/O sont vraiment pas top. Dès qu'il y a un peu de charge, les opérations de lecture/écriture deviennent super lentes. Le iostat me montre des latences énormes. Je suis censé avoir 3000 IOPS sur le gp2 de 1TB. Une idée d'où ça peut venir ?
# iostat -x 1 10 (extrait)
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm aqu-sz await r_await w_await svctm %util
nvme0n1 10.00 120.00 1200.00 5000.00 0.00 0.00 0.00 0.00 5.20 40.00 0.00 40.00 2.00 26.00
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
Commentaires
jules-gregoire
Membre depuis le 05/06/2024
yo ! les chiffres du iostat sont un peu louches. aqu-sz à 5.20 avec %util à 26% et un await à 40ms ça montre que le disque est pas à 100% de son utilisation mais que les requêtes attendent quand même. tu tapes les limites iops de ton gp2 ? le gp2 a un burst et après il redescend. regarde les métriques cloudwatch sur ton volume ebs.
zblot
Membre depuis le 02/09/2024
J'ai checké CloudWatch, le volume ne tape pas ses IOPS limites (burst ou baseline). Il est souvent bien en dessous de 300 IOPS, mais avec des pics de latence quand même.
gturpin
Membre depuis le 30/07/2024
Hmm, si c'est pas les IOPS EBS, c'est peut-être le scheduler I/O de ta VM. Sous Linux, par défaut, c'est souvent CFQ ou Deadline. Lequel tu utilises ? Pour une DB comme PostgreSQL, Deadline ou NOOP sont généralement meilleurs.
zblot
Membre depuis le 02/09/2024
Ah oui, j'avais oublié ça ! Je viens de vérifier, c'est sur CFQ. Je me souviens qu'on avait laissé ça à l'install de CentOS.
francois00
Membre depuis le 22/03/2025
clairement pour une db, cfq est pas le bon choix. il est optimisé pour les desktop users qui ont besoin de fairness entre les processus. change-le pour deadline ou noop. tu peux le faire à chaud :
Mais il faudra le rendre persistant au reboot (via grub ou un fichier udev).
jules-gregoire
Membre depuis le 05/06/2024
Yep, deadline est souvent un bon compromis pour les workloads de bases de données. Noop est plus simple et peut être bon si ton hyperviseur (AWS en l'occurence) gère déjà super bien le scheduling I/O. Teste les deux pour voir lequel te donne le meilleur résultat.
zblot
Membre depuis le 02/09/2024
Ok j'ai basculé sur deadline. Ça a l'air beaucoup plus réactif, les latences iostat sont revenues à des valeurs normales et le PostgreSQL est beaucoup plus fluide. C'était bien le scheduler ! Merci à tous pour l'aide, j'aurais tourné en rond encore longtemps.