7 commentaires
t'as check quel scheduler i/o est actif sur ton disque. souvent cfq est par défaut mais sur les vm ou nvme noop ou deadline peuvent donner de meilleures perfs. cat /sys/block/nvme0n1/queue/scheduler pour voir
c'est du cloud t'es sur que tu consommes pas tes burst credits d'iops. sur aws par ex avec ebs si tu dépasses tes iops de base tu tappes dans le crédit et quand y'en a plus ça rame grave
regarde aussi l'utilisation de ton swap. si ta ram se sature et que tu swappes beaucoup ça peut défoncer les i/o même si ta ram n'est pas "pleine" en apparence
et la config de vm.dirty_ratio ou vm.dirty_background_ratio. si tu fais beaucoup de write le kernel garde en cache et flush d'un coup. si ces valeurs sont trop hautes pour ta ram ça peut causer des latences quand le flush se déclenche
ok les gars merci beaucoup c'était un mix de trucs. j'étais bien en cfq sur le scheduler et en plus oui j'épuisais mes burst credits sur aws. j'ai switché en noop et augmenté la taille du volume ebs pour avoir plus d'iops de base. ça roule impec maintenant
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la compagnie j'ai un truc chelou sur une vm linux (ubuntu 20.04) dans le cloud. elle fait du traitement de données en continu et au bout de 4-5h les perf i/o sur le disque principal s'écroulent. genre au début on est à 500-600 mo/s puis ça descend à 20-30 mo/s. la vm est pas saturée niveau cpu/ram. juste le disque qui rame. un truc dans le kernel qui se passe