10 commentaires
C'est un classique. As-tu vérifié si le netdev_max_backlog n'est pas saturé lors des bursts ? Augmente cette valeur dans sysctl pour voir si ça calme le jeu.
Bien vu, j'ai passé net.core.netdev_max_backlog à 5000, mais ça n'a eu qu'un impact marginal sur le nombre de drops.
Regarde du côté du txqueuelen de l'interface veth. Par défaut, il est souvent très bas, ce qui cause des drops dès qu'il y a une petite rafale de paquets.
Exact, essaie de monter à 1000 avec ip link set dev vethXXX txqueuelen 1000. Ça change souvent tout pour la stabilité.
Je viens d'appliquer le changement sur txqueuelen, c'est nettement plus stable. Je monitor avec ss -i pour confirmer.
D'ailleurs, utilise mpstat -P ALL 1 pour confirmer cette hypothèse de saturation par cœur.
C'est noté. Je vais lancer un bpftrace pour corréler les drops avec les interruptions matérielles. Merci pour les pistes.
Tiens-nous au courant, c'est un cas d'école intéressant pour le tuning réseau.
Problème résolu : c'était bien un mix de txqueuelen trop faible et d'une mauvaise répartition des IRQ. À ne jamais oublier en prod : toujours monitorer ses files d'attente réseau.
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut à tous, je rencontre des pics de latence inexplicables sur des interfaces
vethdans un environnement conteneurisé. Les métriques montrent des drops intermittents au niveau duqdiscalors que le trafic n'atteint même pas 20% de la bande passante théorique.J'ai déjà vérifié les compteurs avec
ethtool -Set je vois desrx_droppedqui montent en flèche. Quelqu'un a déjà eu ce souci sur des noyaux récents ?