3 commentaires
yo. si t'as déjà maxé les iops et throughput du gp3 c bizarre. t'as vérifié la file d'attente sur le device avec cat /sys/block/sdX/queue/nr_requests ? si c'est trop bas ça peut limiter. essaie aussi de voir si c'est des petites écritures aléatoires ou de gros blocs séquentiels. le type de workload affecte bcp les perfs ebs. lance un fio pour simuler ton workload et voir les perfs brutes
en plus des points mentionnés, regarde si t'as pas un souci de scheduler disque. par défaut c'est souvent mq-deadline ou none pour les nvme. pour ebs qui sont virtuels et pas nvme direct, mq-deadline est souvent un bon choix. vérifie avec cat /sys/block/sdX/queue/scheduler. aussi la version du kernel, les 5.x ont des optimisations io_uring qui peuvent aider si tes apps les utilisent
merci pour les pistes ! j'ai vérifié le scheduler c'était bien mq-deadline. en fait le souci venait d'une petite coquille dans la config de mes apps, elles faisaient trop de petites écritures sync. en passant sur du bufferisé et en regroupant les écritures l'iowait est tombé à moins de 10%. j'ai aussi monté nr_requests pour être large. gros soulagement !
Laisser une réponse
Vous devez être connecté pour poster un message !
salut les linuxiens. j'ai des vm ec2 (instance type m5.xlarge) avec des volumes
ebs gp3qui montrent uniowaitsuper élevé, parfois 50-60%. les applications sont lentes à mort. j'ai déjà monté lesIOPSet lethroughputdu volumegp3à fond mais ça change rien.iostat -x 1montre desavgqu-szetawaiténormes. on est sur des ubuntu 20.04 avec le kernel 5.4.x. des idées pour réduire ça ?