13 commentaires
Utilise un job fio avec un mix de lecture/écriture aléatoire pour reproduire la prod. Voici une base :
[global]
size=10G
runtime=60s
iodepth=32
[random-rw]
rw=randrw
blocksize=4kLe burst balance est à 100%. Je suspecte plutôt une contention sur le réseau vu que c'est du EBS.
Regarde les métriques EBSByteBalance% et EBSIOBalance% dans CloudWatch. Si elles tombent à zéro, tu es bridé par AWS.
Tu peux aussi monitorer le iowait avec iostat -x 1 pour voir si tes processus attendent vraiment le disque.
Je viens de vérifier, je suis sur une m5.large, le débit EBS est limité à 4750 Mbps. C'est peut-être là le bottleneck.
Effectivement, avec 4750 Mbps, tu satures très vite si tu fais du logging intensif sur le même volume.
Je te conseille de séparer tes logs des données de ton application sur un volume différent pour isoler les IOPS.
Bonne idée, je vais isoler les logs sur un emptyDir en mémoire pour tester si la latence applicative disparaît.
Si ça marche, migre tes logs vers un sidecar ou un logging driver plus léger comme fluentbit.
Le passage en mémoire a réduit la latence de 60%. C'était bien une saturation du débit EBS lié aux logs. Merci pour l'aide !
Laisser une réponse
Vous devez être connecté pour poster un message !
Hello, j'ai des latences disque inexplicables sur un node EKS. Mes pods ont des IOPS qui chutent brutalement par moments. Je veux valider si c'est un problème de quota EBS ou de saturation du bus.
Quelqu'un a un profil
fiofiable pour simuler une charge réelle et tester les limites de mon volume ?