Localiser les pertes en réception entre NIC, softirq et pile réseau

Des requêtes qui expirent ponctuellement et un compteur de paquets rejetés en réception qui augmente ne signifient pas nécessairement que la carte réseau est défectueuse. Sur un serveur dédié, le chemin de réception traverse les files de la carte réseau, le pilote, les interruptions logicielles et la pile réseau. Un même symptôme peut donc provenir de plusieurs niveaux. Le diagnostic consiste à rapprocher les erreurs applicatives des variations de compteurs sur le même intervalle, et non à augmenter tous les tampons dès que le compteur dropped progresse.

Les exemples suivants utilisent Debian 12 et nécessitent des droits d’administration ainsi que les outils iproute2, ethtool, sysstat et python3. Après le paiement d’un serveur dédié AmdMetal, les identifiants de connexion sont consultables dans la console ; la connexion SSH utilise la première adresse IPv4. Nous commençons ici par des relevés en lecture seule, sans modifier les adresses ni les routes.

1. Identifier l’interface de réception et la période de l’incident

Repérez d’abord avec ip -br address l’interface portant l’adresse utilisée par le service, puis remontez les VLAN, ponts ou interfaces d’agrégation pour trouver l’interface physique qui transporte réellement le trafic. Ne choisissez pas simplement la première carte par ordre alphabétique. Les commandes suivantes demandent de saisir l’interface et créent automatiquement le répertoire des relevés :

read -r -p "Physical interface: " IFACE
ip link show dev "$IFACE" || exit 1
D=$(mktemp -d /var/tmp/rx-audit.XXXXXX)
printf '%s\n' "$IFACE" > "$D/interface"
uname -r > "$D/kernel"
ethtool -i "$IFACE" > "$D/driver"
ip -d link show dev "$IFACE" > "$D/link"
printf '%s\n' "$D"

Notez l’heure des erreurs applicatives, le volume de requêtes, la taille des paquets et la présence éventuelle d’un import par lots. Les compteurs cumulés de l’interface peuvent couvrir une très longue durée de fonctionnement : ils ne permettent pas, à eux seuls, d’établir un lien de cause à effet avec une expiration qui vient de se produire. Un rechargement du pilote, un redémarrage ou la recréation de l’interface peuvent également remettre les compteurs à zéro.

Les statistiques de la carte, de l’interface et de la pile réseau ne constituent pas des comptes indépendants que l’on peut additionner directement. Certains champs peuvent décrire le même événement. Il faut d’abord vérifier leur définition dans le pilote avant d’interpréter leurs variations.

Si l’application s’exécute dans un espace de noms réseau, l’interface physique permet d’observer le chemin de réception de l’hôte, mais les statistiques de la pile réseau doivent aussi être collectées dans l’espace de noms de l’application. L’absence d’erreurs sur l’hôte ne garantit pas que tout fonctionne correctement dans le conteneur.

2. Enregistrer les statistiques de l’interface et du pilote sur le même intervalle

Poursuivez dans le même shell. L’intervalle d’observation de cet exemple est de 30 secondes : il s’agit d’un paramètre de mesure, pas d’un engagement de service. Choisissez une phase d’activité où le problème se manifeste réellement et conservez aussi un relevé témoin de même durée pendant une période normale.

snapshot() {
    label=$1
    date -Is > "$D/$label.time"
    ip -s -s link show dev "$IFACE" > "$D/$label.link"
    ethtool -S "$IFACE" > "$D/$label.nic" 2>&1
    cat /proc/net/softnet_stat > "$D/$label.softnet"
    nstat -az > "$D/$label.protocol"
}
snapshot before
mpstat -P ALL 1 30 > "$D/cpu"
snapshot after
diff -u "$D/before.nic" "$D/after.nic"

Ces lectures sont séquentielles : elles ne forment pas un instantané atomique. En cas de rafales brèves, interprétez-les à l’aide des horodatages, sans exiger une correspondance paquet par paquet entre les fichiers. Si ethtool -S indique que l’opération n’est pas prise en charge, conservez ce résultat : « statistiques indisponibles » ne signifie pas « aucune perte de paquets ».

Vérifier d’abord la signification des compteurs

Si des compteurs d’erreurs dont le nom contient CRC ou frame augmentent, recherchez des indices au niveau de la liaison. Pour les champs contenant missed, no_buffer ou discard, consultez la définition fournie par le pilote utilisé. Ils peuvent concerner les descripteurs de réception, les tampons du périphérique ou le filtrage : leur seul nom anglais ne suffit pas à identifier la cause.

Conservez également les résultats de ethtool -g "$IFACE" et de ethtool -l "$IFACE" pour examiner respectivement les anneaux et les canaux. Le fait que ces requêtes ne soient pas prises en charge ne constitue pas une panne. Les valeurs maximales indiquent seulement les limites du matériel, pas les réglages recommandés en production.

3. Calculer les variations softnet par CPU

/proc/net/softnet_stat contient des valeurs hexadécimales. Ses trois premières colonnes sont, dans l’ordre, processed, dropped et time_squeeze. Les colonnes suivantes peuvent varier selon le noyau et ne sont pas analysées ici. Le script ci-dessous compare les lignes et affiche leur numéro dans le relevé. En cas d’ajout ou de retrait à chaud d’un CPU, recommencez la mesure au lieu de continuer à aligner mécaniquement les lignes.

python3 - "$D/before.softnet" "$D/after.softnet" <<'PY'
import sys
from pathlib import Path

def load(path):
    return [
        [int(v, 16) for v in line.split()[:3]]
        for line in Path(path).read_text().splitlines()
    ]

before, after = map(load, sys.argv[1:])
if len(before) != len(after):
    raise SystemExit("CPU layout changed; sample again")

print("row processed_delta dropped_delta time_squeeze_delta")
for row, (old, new) in enumerate(zip(before, after)):
    delta = [b - a for a, b in zip(old, new)]
    if any(v < 0 for v in delta):
        raise SystemExit("Counter reset or wrap; sample again")
    print(row, *delta)
PY

Une hausse de dropped indique ici des rejets dans la file d’attente logicielle de réception. Une hausse de time_squeeze signifie que des cycles de traitement ont atteint la limite de leur budget ; elle ne prouve pas qu’il y a déjà eu des pertes de paquets. Les statistiques softnet sont agrégées par CPU et ne sont pas propres à une seule carte réseau. Il faut donc écarter l’influence du trafic des autres interfaces sur la même période.

Comparez ces variations à la colonne %soft de mpstat. Une machine dont les CPU sont globalement peu sollicités peut néanmoins subir une forte pression de réception sur un seul cœur : la moyenne d’utilisation ne suffit pas. Si nécessaire, enregistrez /proc/interrupts pour voir si les interruptions des files de la carte se concentrent fortement sur certains CPU. Cette répartition est un indice, pas un critère de validation imposant une distribution uniforme.

4. Choisir le niveau de réglage à partir des observations

Si les compteurs de type missed de la carte augmentent tandis que softnet dropped reste stable, examinez en priorité l’anneau de réception et les files du pilote. À l’inverse, si softnet dropped augmente avec une forte sollicitation d’un seul cœur, examinez la file d’attente logicielle et la répartition du trafic. Si les deux restent stables, comparez ensuite les variations des erreurs de protocole dans nstat et les journaux applicatifs, au lieu de continuer à régler la carte à l’aveugle.

Avant toute modification, enregistrez la configuration actuelle :

ethtool -g "$IFACE" > "$D/rings" 2>&1
ethtool -l "$IFACE" > "$D/channels" 2>&1
sysctl net.core.netdev_max_backlog \
       net.core.netdev_budget \
       net.core.netdev_budget_usecs > "$D/budgets"

N’envisagez de modifier la capacité des anneaux que si le pilote le permet et si les observations le justifient. « Tout mettre au maximum » n’est pas une solution universelle. Agrandir la file d’attente peut réduire les rejets au prix d’une latence d’attente plus élevée ; augmenter le budget de traitement peut empiéter sur le temps d’exécution de l’application. Le réglage de la répartition entre plusieurs files exige aussi de tenir compte des IRQ, du RSS et du nombre de flux applicatifs. Un flux unique ne se répartira pas spontanément sur tous les cœurs.

À distance, ne tentez pas directement une reconfiguration des canaux, un rechargement du pilote ou une réinitialisation de la liaison. Ces opérations peuvent interrompre SSH. Préparez d’abord une procédure d’intervention contrôlée, un relevé des valeurs initiales et un moyen de rétablissement. Ne modifiez qu’un paramètre à la fois et, en cas d’anomalie, commencez par restaurer sa valeur initiale.

5. Valider les résultats avec la charge applicative

Pour le nouveau test, conservez des types de requêtes, une durée et un mode de concurrence comparables, tout en mesurant le trafic réel. Comparer uniquement le nombre absolu de paquets rejetés sur deux intervalles risque de faire passer une baisse de charge pour une optimisation réussie. À débit identique, une proportion plus élevée de petits paquets peut aussi modifier la pression sur le traitement en réception.

La validation doit couvrir au minimum trois ensembles de résultats :

• Indices en réception : les variations des compteurs ciblés diminuent, sans apparition de nouvelles erreurs de liaison. Le fait qu’un total cumulé ne baisse pas ne constitue pas un échec.
• Coût du traitement : aucune nouvelle contention marquée n’apparaît entre la charge des interruptions logicielles par cœur et les besoins CPU de l’application, et la latence d’attente ne se dégrade pas.
• Résultats applicatifs : les expirations, les requêtes en échec et les latences de queue de distribution s’améliorent ensemble ; l’amélioration ne se limite pas aux compteurs de bas niveau.

Si les compteurs de bas niveau restent stables mais que les erreurs applicatives persistent, limitez la conclusion à « aucun indice de rejets en réception correspondant au problème n’a été observé sur cet intervalle ». Poursuivez l’examen de la pile réseau et du traitement applicatif, sans affirmer que le réseau fonctionne parfaitement. Conservez les informations sur l’interface, le pilote et le noyau, les fichiers de mesure ainsi que les valeurs initiales des paramètres modifiés : vous pourrez ainsi vérifier la chaîne causale si les mêmes symptômes réapparaissent.

Questions fréquentes