10 commentaires
As-tu vérifié les métriques CloudWatch pour le volume ? Si tu as atteint la limite de débit ou d'IOPS, EBS throttle tes requêtes en mode silencieux.
Oui, les métriques montrent une utilisation à 90% du quota alloué. Mais ça n'explique pas pourquoi le système semble figé.
Regarde du côté de dmesg pour voir s'il n'y a pas des erreurs blk_update_request. Si le kernel attend trop longtemps, il finit par marquer le filesystem en lecture seule parfois.
Utilise iotop -o pour identifier le processus coupable. Ça pourrait être un backup ou un process logrotate qui sature la bande passante.
Bonne idée, je n'avais pas pensé à iotop en mode batch. Je vais le laisser tourner quelques minutes.
Si tu es sur une instance Nitro, tu peux aussi monitorer les EBSBandwidth via la console EC2 pour corréler les pics.
Si le throughput est le problème, bascule sur du io2 ou augmente simplement la taille du volume GP3 pour obtenir plus d'IOPS par défaut.
Je viens d'identifier le processus : c'est un agent de log qui écrit des fichiers énormes en mode synchrone. Je vais passer en asynchrone pour voir si ça calme le jeu.
Excellente approche. Évite toujours les écritures synchrones sur des disques réseaux si tu n'en as pas strictement besoin pour la cohérence des données.
Problème résolu. Merci pour l'aide précieuse sur l'investigation système.
Laisser une réponse
Vous devez être connecté pour poster un message !
J'ai un nœud EKS qui subit des pics de latence disque énormes sur des volumes EBS GP3. Mes logs
iostatmontrent unawaitqui monte au-delà de 200ms par moment.Comment puis-je isoler si c'est le volume qui sature ses IOPS ou si c'est le kernel qui bloque sur le filesystem ?