11 commentaires
C'est un classique sur EKS quand tu as beaucoup de petits services qui ouvrent/ferment des sockets. Vérifie la valeur de nf_conntrack_count. Si elle sature, le kernel passe son temps à nettoyer la table.
Bien vu. J'ai checké sysctl net.netfilter.nf_conntrack_count et effectivement, on est proche du max. Ça pourrait expliquer le kworker.
Exact. Regarde aussi si tu n'as pas des timeouts trop longs sur tes connexions TCP qui maintiennent des entrées inutiles dans la table.
Ok, je vais ajuster nf_conntrack_tcp_timeout_established. Merci pour le tuyau, je teste ça en staging.
Bon, après analyse, le mpstat montre bien un déséquilibre. Je vais regarder du côté du RSS et de l'affinage des IRQ.
N'oublie pas de monitorer node_netstat_TcpExt_ListenDrops, ça pourrait confirmer une saturation au niveau de la stack IP.
C'était bien ça. Merci à tous pour l'aide, le tuning du conntrack a stabilisé le CPU système. Problème résolu.
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut à tous, je rencontre un problème étrange sur un nœud
m5.2xlargesous EKS. J'ai une montée en charge du CPU système (sys) sans augmentation significative du trafic applicatif. Les métriquesnode_cpu_seconds_totalindiquent que le temps est passé ensystem, ettopaffiche un processuskworkerqui consomme énormément de ressources. Quelqu'un a déjà eu ce genre de souci avec le driver réseau ou le tracking de connexionsconntrack?