Coalescence des interruptions de serveur et optimisation du réseau : guide ultime

Coalescence d'interruption regroupe plusieurs paquets entrants en une seule interruption matérielle, réduisant ainsi la charge du processeur tout en augmentant le débit. Je montre comment ajuster les timings, les seuils et les fonctions NIC telles que RSS et RSC de manière à réduire la latence, la gigue et le temps d'attente. débit s'adapter de manière optimale en fonction de la charge de travail.

Points centraux

Vue d'ensembleLes aspects clés suivants te guideront de manière structurée à travers la technique, le réglage et la pratique.

• Utilisation du CPU: Moins d'interruptions, plus de débit.
• Trade-off de latence: millisecondes contre stabilité et pps.
• Mise au point de NIC: RSS, RSC, MTU et profils d'énergie du BIOS.
• Configuration de l'OS: ethtool, RSC/RSS, files d'attente de pilotes.
• Suivipps, interruptions/s, latence p99.

Interrupt Coalescing en bref

Coalescence signifie que la carte réseau collecte les paquets entrants et ne déclenche une interruption que lorsqu'il y a suffisamment de travail ou qu'un timer expire. Je réduis ainsi nettement le nombre d'interruptions et déplace des parties du traitement des paquets dans la carte d'interface réseau, ce qui réduit la charge du processeur. Sur les serveurs Windows, le Receive Segment Coalescing (RSC) aide en regroupant plusieurs segments en blocs plus grands et en réduisant les coûts de traitement. Sur Linux, je contrôle le regroupement par rx-usecs (temps) et rx-frames (paquets) en fonction des caractéristiques du flux et de la latence cible. Cette approche permet de réduire les frais généraux, de garder les cœurs libres et de stabiliser le débit en cas de fort trafic. L'important reste le compromis délibéré : chaque regroupement ajoute un petit temps d'attente que je limite étroitement pour les flux critiques en termes de latence.

La mécanique : Timings, FIFO et Thresholds

NICs gardent les trames entrantes dans une file d'attente FIFO et déclenchent des interruptions selon deux critères : après x trames reçues ou après y microsecondes. Je définis de petites fenêtres de temps pour les services à faible latence et je les augmente pour les flux à haut débit avec de grandes rafales. Une file d'attente par file de réception améliore la parallélisation, tandis que la modération des interruptions réduit les changements de noyau et utilise mieux le cache. Cependant, des rx-usecs trop élevés ajoutent du retard ; des valeurs trop basses génèrent des tempêtes d'interruptions et poussent le Débit. J'équilibre donc le délai d'attente et la limite des paquets en fonction du MTU, de la taille de la trame et de la proportion de petits paquets.

Modération adaptative et détection de rafales

Coalescence adaptative adapte dynamiquement les fenêtres de temps et de paquets à la charge actuelle. Je l'utilise lorsque les profils de charge varient fortement : lorsque le taux de pps est faible, les fenêtres restent petites (faible latence), lorsque le taux de pps augmente, elles s'élargissent (décharge du CPU). L'utilité dépend du pilote : certains NIC détectent les bursts et augmentent les rx-usecs à court terme, d'autres travaillent avec des niveaux fixes. Je vérifie les Stabilité de la latence du p99 avec l'adaptation activée ; les courbes agitées indiquent des sauts trop agressifs. Pour les services déterministes, je préfère définir des seuils statiques finement choisis, tandis qu'en mode bulk, j'autorise les modes adaptatifs tant qu'il n'y a pas de drops sur l'anneau.

Débit contre latence : le compromis contrôlable

Latence diminue si je désactive le coalescing, mais le CPU travaille alors nettement plus et s'adapte moins bien sous charge. Pour les transferts de fichiers, le streaming ou la réplication, j'accepte un peu de retard, car cela augmente la stabilité et le débit net. Pour la VoIP, le jeu en temps réel ou le HFT, je préfère un retard minimal et je désactive la modération. Je vérifie en complément les Contrôle de la congestion TCP, Les algorithmes tels que CUBIC ou BBR influencent fortement le comportement en cas de perte de paquets, de RTT et de bursts. Avec des minuteries finement ajustées, RSS et des paramètres TCP adaptés, il est possible d'améliorer le compromis optimiser de manière mesurable.

Transmit-Coalescing, TSO/GSO/GRO et LRO

En plus de RX, le TX-Coalescing Les tx-usecs et les tx-frames regroupent les paquets sortants, ce qui économise les changements de contexte et stabilise le transit d'envoi. J'utilise des tx-usecs modérés pour lisser les envois en masse, mais je les garde petits lorsque des réponses courtes (par exemple des API HTTP) doivent sortir rapidement. Les offloads comme TSO/GSO augmentent les segments avant la transmission et réduisent le nombre de paquets, tandis que GRO/LRO fusionner des segments du côté RX. Je valide si GRO/LRO s'harmonisent avec mes middleboxes ; pour certains pare-feux ou exigences de capture, je réduis LRO afin de garder les limites de paquets visibles. Au total, je combine coalescence TX et délestages de telle sorte que les PPS diminuent et que le noyau passe moins de temps en SoftIRQ sans étirer inutilement les temps de réponse.

Réglage de la carte réseau pour les serveurs d'hébergement

RSS (Receive-Side Scaling) répartit les flux entrants sur plusieurs cœurs et empêche qu'un seul cœur ne devienne un frein. J'active RSS et je définis suffisamment de files d'attente de réception pour que les processeurs multi-cœurs fonctionnent efficacement. RSC allège en outre la charge en regroupant des segments plus petits, ce qui réduit le nombre de paquets dans la pile. Pour les charges de travail d'hébergement, je combine la coalescence avec une sélection MTU propre, une priorisation DSCP/QoS et des profils d'énergie CPU dans le BIOS, dans lesquels les C-States et les modes de sommeil profond n'allongent pas la latence. Je teste les combinaisons lors des pics de charge et contrôle si l'affinité IRQ et l'épinglage de la file d'attente préservent la localité du cache. Ainsi, j'apporte nic tuning hosting et interrupt coalescing network en harmonie.

NUMA, MSI-X et Flow-Steering

Sur les hôtes multi-socles, je prends en compte NUMA-J'épingle les files d'attente de réception sur des noyaux proches du slot PCIe et je place les threads de travail correspondants sur le même nœud NUMA. MSI-X-Les interruptions offrent plusieurs vecteurs ; j'en utilise autant que possible pour que chaque file RX/TX ait sa propre interruption et que la contention de verrouillage diminue. En outre, les RPS/RFS/XPS, J'essaie d'orienter les flux vers les „bons“ cœurs et de contrôler l'attribution des transmissions. Je mesure les taux d'échec L1/L2 et j'observe si le trafic cross-core augmente ; si c'est le cas, je réaffecte les files d'attente ou je réduis le nombre de files d'attente afin de renforcer la localité.

Paramètres et leurs effets (tableau)

Paramètres comme rx-usecs, rx-frames, RSS-Queues et RSC déterminent si je minimise plutôt la latence ou si je stabilise le débit. Je commence avec des valeurs conservatrices, je mesure la latence p99 et les interruptions par seconde, puis j'augmente prudemment les fenêtres de temps. Les petites étapes facilitent l'attribution des effets et évitent les erreurs d'interprétation. Si les bursts dominent, j'augmente légèrement les rx-frames et contrôle la répartition de la gigue. Pour les charges de travail mixtes, je varie en fonction du profil VLAN ou NIC afin que Flux avec des objectifs différents fonctionnent séparément de manière optimisée.

Paramètres	Effet	Risque	Convient pour
rx-usecs (temps)	CPU-décharge par fenêtre de temporisation	Plus de latence pour les flux courts	Haut débit, sauvegardes, réplication
rx-frames (paquets)	Regroupe les petits paquets en un Interruption ensemble	Remplissage de la queue pour les rafales	Beaucoup de petits paquets, trafic web
Files d'attente RSS	Traitement à l'échelle sur plusieurs noyaux	Un épinglage incorrect augmente le trafic cross-core	Hôtes multicœurs avec 10-100 Gbit/s
RSC/RSS actif	Moins de charge de paquets dans le Pile	Inadapté à l'ultra-basse latence	Hébergement, virtualisation, stockage

interprétationSi les flux courts dominent, je déplace l'effet vers le minimum de rx-usecs ; pour les transferts en vrac, je fixe des valeurs plus élevées et je profite de la baisse du taux d'interruption. Je vérifie la latence p95/p99 et le PPS après chaque étape afin d'éviter les erreurs de configuration. Au fur et à mesure que la charge augmente, je surveille les temps d'IRQ douce et les changements de contexte pour m'assurer que le temps de l'unité centrale va là où il est réellement utile. Un agencement propre de l'affinité IRQ empêche les interruptions itinérantes entre les cœurs et les sécurités. Cache-concordance.

Pratique : Windows Server et Linux

WindowsDans le gestionnaire de périphériques, j'ouvre les propriétés de la carte réseau, je sélectionne „Avancé“ et j'adapte la modération d'interruption, le RSS et éventuellement le RSC ; pour une latence faible et dure, je règle la modération sur „Disabled“. Je règle les profils d'alimentation sur une puissance élevée, afin que les C-States ne prolongent pas le temps de réaction. LinuxAvec ethtool, j'ajuste les rx-usecs/rx-frames et je contrôle les compteurs d'IRQ et d'erreurs avec ethtool -S ; irqbalance ou l'affinity pinning explicite assigne les queues aux noyaux. Pour les très petits paquets, j'expérimente avec GRO/LRO et je vérifie si le chemin utilisateur ou le chemin du noyau est le goulot d'étranglement. Je donne plus de profondeur à ce sujet dans mon guide sur les Optimiser les interruptions du CPU, Il s'agit d'un document qui décrit des étapes mesurables et des contrôles croisés.

Virtualisation et Cloud : SR-IOV, vSwitch et vRSS

Dans les environnements virtualisés, le Chemin d'accès des paquets le réglage optimal. Avec SR-IOV les VF contournent l'overhead vSwitch ; je règle le coalescing directement sur le PF/VF et je veille à ce que l'invité et l'hôte appliquent des politiques similaires. Dans les scénarios vSwitch (Hyper-V, Open vSwitch), des files d'attente et des planificateurs supplémentaires interviennent ; vRSS répartit la charge au sein de la VM sur plusieurs vCPU. Je mesure si le coalescing s'applique dans l'hôte ou dans la VM et j'évite la double modération avec des fenêtres trop grandes. Pour les charges de travail NFV/DPDK, le travail est déplacé dans l'espace utilisateur ; j'y adapte les budgets de sondage et je garde le coalesçage du noyau conservateur afin de ne pas fausser les mesures.

Mesure de la performance et télémétrie

Mesure assure toute optimisation, c'est pourquoi je suis les pps, les octets/s, les interruptions/s, les temps de SoftIRQ, les drops et la longueur de la file d'attente. Je compare la latence p50/p95/p99 et observe le comportement des bursts, car les valeurs moyennes masquent les valeurs extrêmes. Pour HTTP/2/3, je mesure la densité des connexions, le taux de requêtes et le temps CPU par requête afin de détecter les effets latéraux du coalescing. Les nœuds de stockage profitent de l'observation conjointe de l'iowait, de la charge IRQ et de la latence du réseau, car les goulots d'étranglement se déplacent volontiers entre les couches de la pile. Tableaux de bord avec des événements et des temps de déploiement aident à attribuer clairement les étapes de réglage et à arrêter immédiatement les régressions.

Protocoles sensibles au temps et horodatage matériel

Pour les protocoles avec un chronométrage précis (par ex. PTP), je vérifie si la coalescence affecte la précision de l'horodatage. Certaines cartes réseau offrent des horodatages matériels qui sont définis avant le coalescing - idéal pour la précision des mesures. Dans de tels cas, je désactive LRO/GRO et réduis rx-usecs au minimum afin que les variantes de latence ne perturbent pas la synchronisation temporelle. Pour les réseaux déterministes (TSN), je mets à plat les modes d'économie d'énergie, je règle strictement la QoS et je confirme qu'aucune file d'attente ne génère de débordements qui menacent la stabilité de la cadence.

Les profils de charge de travail : Quand activer, quand ne pas activer ?

Haut débit: Les sauvegardes, l'origine CDN, le stockage d'objets et la réplication de VM profitent fortement du coalescing, car le CPU est moins perturbé. Hébergement web avec de nombreuses petites requêtes a besoin de valeurs modérées, combinées à RSS et à une bonne localisation du cache. Les environnements virtuels gagnent à ce que je définisse des valeurs par défaut intelligentes par vNIC et que j'isole les bruits de fond (noisy neighbors). Pour la VoIP, le jeu ou la télémétrie en temps réel, je désactive la modération ou je définis des timers très serrés. Les mesures en fonction du profil de trafic sont obligatoires, car 10 Gbit/s Bulk se comporte différemment du trafic API de 1 Gbit/s.

Tailles des bagues, comportement du buffer et du drop

En plus des minuteries, les Tailles des bagues (descripteurs RX/TX) la résilience en cas de rafales. J'augmente modérément les descripteurs RX lorsque de courts pics provoquent des drops, en faisant attention à l'empreinte mémoire et à la fitness du cache. Des anneaux trop grands masquent les problèmes, mais prolongent les temps d'attente dans le pipeline. J'observe les „rx_no_buffer“, „dropped“ et „overruns“ dans les compteurs statistiques et compare les seuils aux longueurs de rafales typiques. Une combinaison finement équilibrée de rx-frames, rx-usecs et de taille d'anneau évite que Bursts entraîner des pertes ou des pics de gigue.

Jitter, pertes de paquets et gestion des rafales

Jitter se produit lorsque la fenêtre de coalescence et le modèle de rafale interagissent de manière défavorable ; je le reconnais aux larges distributions de latence. De petits sauts de temporisation permettent souvent de lisser la courbe p99 sans réduire le débit de manière visible. Si la carte d'interface réseau est en surcharge, je définis des valeurs moins agressives et je vérifie la profondeur de la file d'attente et les niveaux des pilotes. Pour les sites web, l'analyse de Gigue réseau, pour rendre les requêtes de blocage de rendu et les handshakes TLS prévisibles. Enfin, je vérifie si les politiques de QoS séparent proprement les classes de priorité, ce qui permet d'éviter les problèmes critiques. Flux préfèrent.

Liste de contrôle pratique pour le tuning

Lancement avec une ligne de base : Je saisis la latence, les pps, les interruptions/s et le profil du CPU avant chaque modification. Ensuite, j'active RSS/RSC, je définis des valeurs de coalescence modérées et je mesure à nouveau p50/p95/p99. Ensuite, j'augmente rx-usecs par petites étapes jusqu'à ce que la gigue ou la latence p99 augmente, et je reviens au dernier bon point. J'assigne des queues à des noyaux fixes et surveille les échecs de cache ; si le trafic cross-core augmente, j'ajuste l'affinité. Je documente brièvement chaque changement et compare les pics de charge afin que les Stabilité ne souffre pas en secret.

Exemple de valeurs de départ selon la vitesse du lien

• 1 Gbit/s: rx-usecs 25-50, rx-frames 8-16, tx-usecs 25-50 ; peu de queues RSS (2-4), focalisation sur la latence.
• 10 Gbit/s: rx-usecs 50-100, rx-frames 16-32, tx-usecs 50-100 ; 4-8 files d'attente RSS, GRO on, LRO sélectif.
• 25/40 Gbit/s: rx-usecs 75-150, rx-frames 32-64, tx-usecs 75-150 ; 8-16 queues, épinglage NUMA strict, RSC/RSS actif.
• 100 Gbit/s: rx-usecs 100-200, rx-frames 64-128, tx-usecs 100-200 ; 16-32 queues, utiliser pleinement MSI-X, augmenter modérément la taille des anneaux.

Remarque: Ce sont des entrées conservatrices. J'optimise le long de la latence p99 et des drops et je tiens compte de la taille des paquets (MTU 1500 vs. Jumbo), du mélange de flux et de la topologie du CPU.

Coûts, énergie et durabilité

Énergie diminue lorsque j'appuie sur le taux d'interruption, car le CPU effectue moins de changements de contexte et de réveils. Dans les centres de données, cela s'additionne sur de nombreux hôtes et réduit sensiblement les coûts d'électricité et de refroidissement. Une mise à niveau vers des cartes réseau 10/25/40/100G modernes avec une bonne modération coûte généralement quelques centaines d'euros, mais elle est souvent rapidement amortie par la réduction du temps CPU par octet. Je tiens compte du fait que les licences, la maintenance des pilotes et le monitoring sont déjà disponibles afin de maintenir les frais courants à un niveau bas. Pour les services critiques en termes de SLA, il vaut la peine de choisir une fenêtre conservatrice qui Jitter et sécurise l'expérience de l'utilisateur.

Dépannage et anti-patterns

Montrer les métriques Tempêtes d'interruptions, je réduis les queues RSS ou j'augmente légèrement les rx-usecs. Pour les courbes de latence „wobbly“, je désactive la modération adaptative à titre d'essai. Si des drops se produisent malgré des réserves élevées du CPU, je vérifie la taille des anneaux, le niveau du firmware et la gestion de l'état de la puissance PCIe-Link. Un classique : Coalescing très élevé + GRO/LRO actif cache les pertes de paquets dans p50, tandis que p99 en souffre - je rééquilibre alors les rx-frames et raccourcis les rx-usecs. Pour les hôtes multi-locataires, les „voisins bruyants“ provoquent une charge d'IRQ inégalement répartie ; j'utilise des masques d'affinité durs et des classes de QoS pour éviter les problèmes critiques. Flux de protéger les données. Important : toujours déployer les modifications individuellement et les tester par rapport à des profils de charge identiques afin de séparer clairement les causes et les effets.

Résumé : Plus rapide, plus calme, plus prévisible

Idée centraleInterrupt Coalescing réduit les perturbations, distribue le travail plus intelligemment et renforce le débit net, tant que je définis les temporisateurs et les limites de paquets de manière ciblée. Pour les services à haut débit, j'opte pour des fenêtres plus larges, pour les services en temps réel, je choisis une modération minimale ou désactivée. Avec RSS, RSC, une discipline MTU et une affinité IRQ propre, j'exploite pleinement les CPU multicœurs. Des mesures avec p95/p99, des interruptions/s et des temps d'IRQ soft sécurisent chaque modification et empêchent les erreurs d'interprétation. Ainsi, mon Réseau calme en charge, réagit rapidement et fournit des latences prévisibles pour l'hébergement et les applications.