Passer au contenu 
En cas de charge de paquets élevée, je mise sur un network buffer tuning conséquent, car des tampons de noyau, de socket et de NIC étroitement coordonnés réduisent le temps de réponse et évitent les trames perdues. Pour cela, j'utilise les valeurs mesurées des queues drops, des retransmissions et des pics PPS pour définir la taille des tampons, les fenêtres TCP et les files d'attente de manière à ce que les bursts soient interceptés et que la latence reste basse de manière fiable.
Points centraux
- Tailles des tampons adapter dynamiquement par profil de charge
- Stratégies de file d'attente pour commander RX/TX
- Pile TCP utiliser des algorithmes modernes
- Déchargement et utiliser la distribution IRQ
- Suivi comme base de décision
Pourquoi les tampons décident de la performance
Une bande passante élevée suffit rarement à elle seule, car Files d'attente et les limites de socket fixent souvent la limite plus tôt que le lien. Si les paquets arrivent en rafales, je les intercepte avec des tampons de réception et d'émission suffisamment dimensionnés pour que le noyau les transmette rapidement à la pile. Des tampons trop petits génèrent des erreurs inutiles. Retransmissions et des délais d'attente, ce qui diminue sensiblement la capacité utile du PPS. En revanche, des tampons surdimensionnés entraînent un bufferbloat, c'est-à-dire un retard supplémentaire malgré une unité centrale et une ligne libres. Pour la base des réglages, j'explique volontiers les principes de base de manière compacte et renvoie pour les détails à Comprendre les tampons de socket, Les vis de réglage déterminent précisément le temps de réaction lors de l'acceptation et de l'envoi.
Utiliser judicieusement les profils de charge et le monitoring
Avant d'ajuster les valeurs, j'accumule des données difficiles Métriques: connexions simultanées, paquets par seconde, abandons de file d'attente, retransmissions et temps de softIRQ du CPU. Je lis dans les courbes si le goulot d'étranglement se trouve dans le chemin RX, dans le chemin TX, dans le handshake TCP ou dans l'application. Si la carte réseau montre des drops alors que la réserve de l'unité centrale est pleine, j'en déduis que les files d'attente de réception sont trop petites ou que la répartition des interruptions est défavorable. Si je vois beaucoup de retransmissions sans erreurs d'interface, je vérifie la pile TCP, le contrôle de congestion et les tampons pour les petits objets. Ce n'est que lorsque ces Symptômes Si les problèmes de mémoire sont clairs, il vaut la peine de passer à l'étape suivante en utilisant des paramètres de noyau ciblés plutôt que d'augmenter la mémoire de manière générale.
Paramètres Linux avec effet
Pour les pics de charge, je mets à l'échelle les centrales Valeurs du noyau modérément vers le haut et je valide ensuite la latence. Je veille à adapter aussi bien les valeurs maximales que les triplets d'autotuning (rmem/wmem), afin que la pile puisse croître de manière dynamique. Les tailles du backlog sur le socket et l'interface réseau empêchent les drops lorsque Userland se bloque brièvement. Je raccourcis ou j'allonge les valeurs de timeout en fonction de la charge de travail, afin que les connexions se terminent de manière appropriée. Le tableau suivant fournit des points de départ que je compare à des modèles réels dans la zone de test et que je mesure ensuite en fonctionnement.
| Paramètres | Effet | valeur initiale | Remarque |
|---|---|---|---|
| net.core.rmem_max | Max. Tampon RX par socket | 16M-32M | Choisir plus haut pour beaucoup de petits paquets |
| net.core.wmem_max | Max. Tampon TX par socket | 16M-32M | Aide en cas de retard du client |
| net.ipv4.tcp_rmem | Tuning automobile RX [min/def/max] | 4096 87380 33554432 | Max correspondant à rmem_max |
| net.ipv4.tcp_wmem | Tuning automobile TX [min/def/max] | 4096 65536 33554432 | Max correspondant à wmem_max |
| net.core.netdev_max_backlog | Noyau-arriéré pour RX | 8192–65536 | Décisif pour les bursts RX |
| net.ipv4.tcp_fin_timeout | Durée pour FIN État | 15-30 | Moins d'occupation TIME_WAIT |
| net.ipv4.tcp_congestion_control | Algorithme pour Contrôle des embouteillages | bbr/cubic | Tester selon le RTT/PPS |
Gestion des files d'attente sur l'interface réseau
Dans le chemin NIC, j'adresse d'abord la Recevoir- et les queues de transmission, car les anneaux RX pleins entraînent immédiatement des drops. Les pilotes modernes permettent plusieurs files d'attente RX/TX par cœur de CPU, ce qui lisse la latence en cas de parallélisme élevé. Je fais évoluer la taille des anneaux vers le haut, sans les surétendre, et je vérifie si GRO/LRO correspond à la charge de travail. Si les petits paquets et la faible latence sont importants, je désactive le coalescing excessif ou je définis des temporisateurs d'interruption plus serrés. Pour ceux qui veulent aller plus loin, voir files d'attente de réception et de transmission une bonne mise en perspective des limites, des luttes et des effets de coalescence dans la vie quotidienne.
Régler finement la pile TCP
En cas de nombreuses sessions simultanées, un système cohérent de Taille de la fenêtre Miracle, car les Windows trop petits n'exploitent pas le produit RTT. J'active systématiquement le Window Scaling et je choisis bbr ou cubic selon le chemin du réseau, puis je vérifie les taux de retransmission et le goodput. Les connexions persistantes avec des intervalles keep-live modérés réduisent sensiblement l'overhead du handshake à trois voies. En outre, je tiens compte des Delayed ACKs, de l'Initial Congestion Window et du SYN-Backlog, afin que le serveur reste acceptable sous les pics. Pour une introduction rapide au réglage fin, voir Mise à l'échelle de la fenêtre TCP, La dynamique entre le RTT, la bande passante et les tampons de socket est ainsi rendue tangible.
Délestage matériel et répartition de l'unité centrale
En dehors de la pile, je puise Offloads de la carte réseau : Checksum, TSO/TSO6, UFO, GRO et GSO réduisent le travail du CPU par paquet. Pour les charges de travail avec des mini-trames, je considère GRO/GSO comme critique, car de grandes agrégations peuvent augmenter sensiblement la latence. RSS, RPS et RFS répartissent les flux RX de manière uniforme sur les cœurs, ce qui fait disparaître les points chauds d'IRQ logiciels. J'épingle judicieusement les IRQ aux ensembles de CPU et je garde les Userland-Worker à proximité des flux de données. Cette Affectation allège la charge de travail du planificateur et augmente la cohérence des temps de réponse.
Tuning pour les charges de travail typiques
Pour les sites web classiques avec de nombreux petits Objets je me concentre sur une faible latence, des anneaux RX/TX modérés et des valeurs Keep-Alive réduites. Les backends API bénéficient de délais d'attente courts, d'un backlog SYN plus agressif et d'un autotuning fiable des tampons de socket. Le streaming en direct exige des tampons d'émission élevés, des anneaux TX stables et un contrôle de congestion adapté aux RTT moyens. Les serveurs de jeux ont besoin de mémoires tampons serrées, de temporisations de coalescence étroites et d'un délai de mise en file d'attente aussi faible que possible au lieu d'un débit de données maximal. Les nœuds CDN équilibrent le débit et la latence en conduisant de grands Windows, mais en limitant le bufferbloat par AQM ou une discipline de file d'attente stricte.
Approche itérative et tests de charge
Je modifie des paramètres dans Étapes et j'applique des tests de charge reproductibles après chaque tour. Je détermine ainsi si c'est netdev_max_backlog ou rmem_max qui fournit le plus grand levier. Je compare ensuite les latences médianes et P95, les PPS, les drops et les retransmissions et déploie la meilleure combinaison en production. Je vérifie les pics temporaires séparément, car les pointes courtes montrent d'autres limites que la charge continue. Cette approche disciplinée Procédure évite les effets secondaires tels que l'augmentation de l'utilisation de la mémoire ou les délais d'attente retardés.
Éviter les pièges de la performance
Le piège le plus courant s'appelle BufferbloatDes tampons trop généreux cachent des drops, mais augmentent massivement le temps d'attente. C'est pourquoi je m'oriente vers des objectifs de latence et pas seulement vers le goodput, surtout pour les petites réponses comme les fragments HTML ou JSON. Je fais également attention aux cookies SYN et aux limites de backlog, afin que les rafales ne soient pas interrompues lors de l'établissement de la connexion. Un coalesçage excessif des interruptions rend les chiffres plus beaux dans les benchmarks, mais les utilisateurs ressentent le retard dans la réalité. Ceux qui respectent les limites de Queues de billard Le meilleur moyen de comprendre le fonctionnement d'un projet est d'examiner les liens entre les anneaux, le backlog et les drops, comme on peut le voir dans de nombreux rapports pratiques.
Interaction avec la mise en cache et Keep-Alive
Le tuning réseau déploie ses effets Effet que si je travaille simultanément sur la mise en cache, la compression et la réutilisation de la connexion. Timme Hosting met en avant les effets de la mise en cache par navigateur, du GZIP et des temps de maintien en ligne plus longs, ce que je peux clairement vérifier par des mesures. Raidboxes rappelle que des ressources de serveur suffisantes constituent la base pour que les tampons ne se vident pas en raison de goulots d'étranglement du processeur. Hosttech attire l'attention sur les limites qui s'appliquent en cas de charge trop élevée et qui exigent alors soit une optimisation soit une augmentation des performances. Au total, la combinaison de l'affinage TCP, des réglages de la mémoire tampon et de l'optimisation des applications donne des résultats tangibles. plus court Temps de réponse en cas d'accès simultané.
Valeurs limites et points de mesure pratiques
Je prévois un départ pour rmem_max et wmem_max 16-32 MB et je règle tcp_rmem/tcp_wmem pour que l'autotuning puisse s'y développer. Je choisis netdev_max_backlog avec 16k à 64k entrées, tandis que je mets à l'échelle les anneaux RX/TX de la NIC selon les recommandations du pilote. Dans lspci, ethtool -g et -k, je vérifie quels offloads et quelles tailles d'anneau sont disponibles. Pour le backlog SYN, je définis des valeurs qui correspondent au débit d'acceptation réel de l'application au lieu d'exploiter uniquement la limite supérieure. L'important reste la Mesure après chaque modification : je collecte les percentiles de latence, les PPS, les drops, le chargement de SoftIRQ et les codes d'erreur des apps dans le contexte.
Spécificités des petits et des grands paquets
Les petits paquets demandent PPS-C'est pourquoi je diminue prudemment le coalescing et affine la répartition des IRQ. Les gros paquets bénéficient du TSO/GSO tant qu'ils ne font pas exploser la MTU cible et qu'il n'y a pas de risque de fragmentation. Pour les charges mixtes, je trouve un juste milieu : des tampons modérés, un coalescing adaptatif et un contrôle de congestion qui fonctionne proprement lorsque les RTT changent. J'utilise TCP_NODELAY de manière sélective pour les flux à latence critique, tandis que je préfère le regroupement pour les transferts en vrac. Cette différenciation Traitement veille à ce qu'aucun modèle de charge ne domine l'ensemble de l'instance.
Déployer la configuration avec précaution
Dans la pratique, je déroule de nouveaux Paramètres d'abord sur des nœuds de staging, où je les teste avec des tests réalistes. Ensuite, je les active progressivement sur des serveurs de production et je surveille de près la télémétrie. Je prépare des plans de retour en arrière au cas où les temps d'attente ou les retransmissions augmenteraient involontairement. Je rassemble les paramètres dans des playbooks scriptés afin que chaque modification reste compréhensible. C'est ainsi que je garde le Risque et d'obtenir des avantages mesurables sans surprises.
Liste de contrôle sans orgies de bulletins
Je commence toujours par des Objectifs pour la latence et le débit, je définis des valeurs cibles PPS et des taux d'erreur acceptables. Ensuite, je mesure les valeurs réelles et identifie les goulots d'étranglement au niveau de la carte réseau, du backlog du noyau, des tampons de socket et de la pile TCP. Ensuite, je définis des valeurs de départ modérées, je les documente et j'effectue des tests de charge A/B avec des scénarios constants. Ensuite, j'inspecte les percentiles et les drops, j'ajuste par petites étapes et je répète le test. Enfin, j'ancre durablement les meilleures valeurs dans les profils Sysctl et ethtool, afin que Consistance reste garantie.
Fonctionnement dans des VM et des conteneurs
Dans les environnements virtualisés, j'ajuste les mêmes vis de réglage, mais je fais particulièrement attention à la Virtio/vhost-coûts des chemins d'accès et goulots d'étranglement possibles entre l'hôte et l'invité. Je préfère les pilotes paravirtualisés (virtio-net) avec plusieurs files d'attente et j'active le délestage sur l'hyperviseur via vhost-net. Si la latence est critique, je vérifie SR-IOV ou le contournement de l'hôte pour des charges de travail sélectionnées, car cela réduit les coûts de copie et les changements de contexte. Les conteneurs héritent des paramètres du noyau et de la carte réseau, mais des limites telles que somaxconn, J'utilise les paramètres d'ouverture de fichiers et les budgets de cgroup pour chaque pod/service afin que les pics de bursts dans le pays utilisateur n'échouent pas à cause des limites de l'espace de nommage. Important : les anneaux RX/TX et l'affinité IRQ sur l'hôte doivent correspondre au placement des systèmes invités, sinon les paquets se déplacent au-delà des limites NUMA et augmentent la latence de queue.
NUMA, affinité IRQ et busy polling
Sur les serveurs multi-sockets, je conserve les données NUMA-localJe lie les files d'attente RSS de la carte réseau aux noyaux du même domaine NUMA que celui dans lequel le processus d'application est exécuté. RPS/RFS et XPS contrôlent le chemin d'affinité de flux, ce qui augmente les hits de cache et diminue les hotspots SoftIRQ. Pour cela, je crée des masques IRQ fixes et ne laisse irqbalance intervenir que de manière limitée. Pour une latence extrêmement faible, je teste Busy-Polling (net.core.busy_read / busy_poll) de manière sélective sur quelques sockets, car cela permet d'économiser des réveils - mais toujours en tenant compte du budget CPU et de l'équité. De plus, net.core.netdev_budget et net.core.netdev_budget_usecs influencent la quantité de travail effectuée par poll NAPI ; je les ajuste avec précaution pour que les rafales RX ne restent pas bloquées et que les autres tâches reçoivent quand même du CPU.
Découverte MTU, MSS et Path-MTU
Propre MTU-Les chaînes de transmission sont essentielles : je coordonne l'hôte, le commutateur et le flux montant avant d'activer les trames jumbo. En cas de fragmentation ou de blocage de la découverte PMTU, les retransmissions et la latence augmentent. C'est pourquoi je définis un clampage MSS adapté au chemin et je vérifie les drapeaux DF sur les trajets critiques. Pour les graphismes mixtes (VPN, réseaux superposés), je calcule l'overhead et maintiens la MTU effective cohérente afin que ni GRO/TSO ni GSO ne trébuchent. Une MTU plus petite peut même aider dans les scénarios WAN lorsque les délais de mise en file d'attente dominent et que le microbatching n'est pas souhaitable.
Charges de travail UDP/QUIC et non-TCP
Toutes les charges ne sont pas TCP : pour UDP il manque des retransmissions dans la pile, je dimensionne donc plus généreusement les tampons rmem/wmem et de socket et je vérifie les options UDP-GRO/GSO de la carte réseau. Pour QUIC, je veille à ce que les délais de mise en file d'attente soient faibles, à ce que les timings soient stables et, le cas échéant, à ce qu'il n'y ait pas d'interruption de service. ECN, Les implémentations modernes sont sensibles à une signalisation propre. Comme UDP ne connaît pas de backlog d'acceptation, l'accent est mis sur les anneaux RX, le backlog netdev et une distribution équitable par RSS. Pour les feux d'artifice de télémétrie (Syslog, Metrik-Push), j'étrangle à l'expéditeur ou j'utilise des files d'attente prioritaires pour que le trafic de contrôle ne supplante pas les données utiles.
Gestion de la file d'attente active, qdiscs et pacing
À l'adresse suivante : Bufferbloat je mise sur des qdiscs avec AQM (par ex. des variantes basées sur CoDel) ou sur des disciplines basées sur FQ qui séparent les flux et les mettent en pacing. En combinaison avec le BBR ou le Cubic moderne, je lisse ainsi les bursts sans couper inutilement le débit. Il est essentiel de ne pas laisser la couche qdisc travailler contre le matériel : Si la carte réseau est déjà fortement coalescée ou regroupe les offloads, je choisis des paramètres AQM conservateurs et je vérifie si la file d'attente matérielle n'est pas le véritable goulot d'étranglement. Pour les services prioritaires (par exemple les chemins de contrôle), une petite bande stricte avec une latence serrée peut aider, tandis que les transferts en vrac vivent avec une plus grande mémoire tampon.
Approfondir l'observabilité
En plus des counters classiques, je m'appuie sur ethtool -S (anneaux, drops, stats de coalescence), ss (télémétrie de la chaussette), nstat (erreur IP/TCP), dropwatch (où les paquets sont-ils perdus ?) et les sondes eBPF ciblées. Je compare les métriques d'application avec les valeurs du noyau : si les retransmissions augmentent sans erreurs de NIC, la cause se trouve souvent dans le chemin de congestion ou dans des timeouts défectueux au-dessus. J'enregistre les percentiles de latence séparément pour RX, temps d'application et TX et j'arrête la mesure. reproductible (charges utiles identiques, phases de réchauffement, germes aléatoires constants) pour que les itérations soient significatives. Sous parallélisme élevé, je regarde le temps de SoftIRQ par cœur et la longueur de la file d'attente afin de séparer les influences de l'ordonnancement des véritables goulots d'étranglement du réseau.
Sécurité, résilience et hygiène conntrack
Contre les pics de charge dus à un comportement erroné ou malveillant, je sécurise les bords : Cookies SYN Je tiens le backlog SYN à disposition, je le dimensionne de manière réaliste et je vérifie si l'application peut traiter les pics d'acceptation. Si les systèmes utilisent Conntrack (par ex. pour DNAT), je place nf_conntrack-La capacité et les timeouts doivent être adaptés à la surface de la session, sinon les nouveaux flux seront perdus. Des limiteurs de débit sur la périphérie et des filtres matériels sur la carte réseau protègent les anneaux RX ; pour les sources très bruyantes, il vaut la peine d'utiliser un drop-path précoce. Parallèlement, je réduis la journalisation coûteuse dans le chemin critique, car les pics d'E/S peuvent contrecarrer le travail de mise en mémoire tampon.
Tuning proche de l'application et des sockets
Côté apps, j'utilise SO_REUSEPORT, pour répartir les écouteurs sur les noyaux, et définir le backlog de liste de manière cohérente par rapport à somaxconn. Un chemin d'acceptation cohérent avec une capacité de worker suffisante empêche que le backlog du noyau ne soit utilisé abusivement comme tampon caché. Pour les RPC critiques en termes de latence, je teste de manière sélective TCP_NODELAY, Pour les objets en vrac, je reste sur le regroupement. Pour les très nombreuses connexions courtes, TCP Fast Open est utile dans les scénarios appropriés - mais uniquement si la compatibilité avec la middlebox est vérifiée. Les serveurs qui génèrent un nombre extrêmement élevé de petites écritures bénéficient en partie d'E/S basées sur io_uring et d'une charge de syscall réduite ; au total, je décharge ainsi le chemin entre les buffers du pays utilisateur et les files d'attente NIC.
Profils énergétiques et détails du noyau
Je fais attention CPU-C-States et le gouverneur de fréquence : les états de sommeil profonds économisent de l'énergie, mais coûtent du temps de réveil. Pour les pics de charge planifiables, je passe à un gouverneur performant et je limite les C-States bas jusqu'à ce que la latence cible soit atteinte. Du côté de la carte réseau, je vérifie les fonctions d'économie d'énergie qui décalent les taux d'interruption ou les temporisateurs. Côté noyau, je garde actives les fonctions TCP telles que SACK et les timestamps, à condition qu'aucune appliance spéciale ne vienne interférer, et je vérifie l'utilisation d'ECN dans les chemins réseau qui supportent la signalisation propre. Je versionne mes ensembles Sysctl et maintiens la cohérence des états du noyau et des pilotes - de petites différences modifient en partie le comportement de l'autotuning et faussent les résultats.
En bref
Un Server Network Buffer Tuning efficace s'appuie sur des données dures Métriques, des réglages ciblés du noyau et du TCP et une configuration propre de la carte réseau. Je combine l'autotuning des sockets, des anneaux RX/TX appropriés, un contrôle moderne de la congestion et un déchargement bien dosé afin d'absorber les pics de burst et de maintenir les temps de réponse constants. Dans les scénarios d'hébergement avec WordPress, WooCommerce ou API, cela s'avère nettement payant avec la mise en cache, la compression et le Keep-Alive. En testant, en enregistrant et en répétant les étapes, on obtient de manière fiable une capacité PPS plus élevée avec une latence plus faible. Ainsi, le système reste performant en cas de charge élevée réactif et les images d'erreur se produisent moins souvent.
