3 commentaires
Si tu veux descendre plus bas, funclatency sur les fonctions tcp_v4_do_rcv peut t'aider à voir si c'est le traitement des paquets entrants qui sature.
J'ai lancé tcpconnlat et j'ai vu des temps de réponse de 500ms sur certaines résolutions DNS locales. C'était un problème de conntrack sur mes noeuds worker. Merci pour le tuyau eBPF !
Laisser une réponse
Vous devez être connecté pour poster un message !
Mon application Go a des pics de latence aléatoires que je ne vois pas dans Prometheus. Je soupçonne la stack réseau du kernel mais je ne sais pas comment isoler ça.
Est-ce qu'il y a une commande simple avec eBPF pour voir quel syscall ou quelle étape réseau prend du temps ?