Performances I/O sur VM Linux trop lentes

Question

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

jules-gregoire · Answer

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 · Answer

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 · Answer

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.

cat /sys/block/nvme0n1/queue/scheduler

zblot · Answer

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 · Answer

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 :

echo deadline | sudo tee /sys/block/nvme0n1/queue/scheduler

Mais il faudra le rendre persistant au reboot (via grub ou un fichier udev).

jules-gregoire · Answer

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 · Answer

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.

Performances I/O sur VM Linux trop lentes

Commentaires

Laisser une réponse

Faciliter le déploiements k8s avec Kustomize

Conclusion du cours sur le DevOps

Comprendre et utiliser Filebeat dans la stack ELK

Rejoindre la communauté