{"id":19569,"date":"2026-06-01T08:35:01","date_gmt":"2026-06-01T06:35:01","guid":{"rendered":"https:\/\/webhosting.de\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/"},"modified":"2026-06-01T08:35:01","modified_gmt":"2026-06-01T06:35:01","slug":"softirq-cpu-hosting-optimisation-du-debit-reseau-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/","title":{"rendered":"softirq cpu hosting : Optimiser les performances du serveur et le d\u00e9bit du r\u00e9seau"},"content":{"rendered":"<p>Je montre comment <strong>softirq cpu<\/strong> avec NAPI, la r\u00e9partition IRQ et la conception de la file d'attente, limite ou lib\u00e8re le d\u00e9bit du r\u00e9seau dans l'h\u00e9bergement. Avec des points de mesure clairs, un r\u00e9glage cibl\u00e9 et des affinit\u00e9s propres, je r\u00e9duis <strong>Latence<\/strong> et augmente de mani\u00e8re coh\u00e9rente le d\u00e9bit pps sur les serveurs de production.<\/p>\n\n<h2>Points centraux<\/h2>\n<p>Ces id\u00e9es centrales transportent efficacement les paquets r\u00e9seau via le CPU, le noyau et la carte r\u00e9seau - et maintiennent les temps de r\u00e9ponse <strong>constant<\/strong> bas.<\/p>\n<ul>\n  <li><strong>Budget du NAPI<\/strong> un r\u00e9glage fin : Un plus grand nombre de paquets par poll r\u00e9duit l'overhead et lisse la qualit\u00e9. <strong>Charge CPU<\/strong>.<\/li>\n  <li><strong>\u00c9quilibrage de l'IRQ<\/strong> et affinit\u00e9 : \u00e9viter les points chauds, augmenter les occurrences de la cache, <strong>Pics de latence<\/strong> Appuyez sur .<\/li>\n  <li><strong>Multi-queues<\/strong>, RSS\/RPS\/XPS : parall\u00e9liser les flux, pr\u00e9server l'alignement NUMA, <strong>pps<\/strong> soulever.<\/li>\n  <li><strong>Offloads<\/strong> utiliser en connaissance de cause : \u00c9valuer GRO\/LRO, TSO, Coalescing, <strong>Jitter<\/strong> garder \u00e0 l'esprit.<\/li>\n  <li><strong>Isolation<\/strong> et Busy Polling : temps de r\u00e9ponse pr\u00e9visibles sur des sites d\u00e9di\u00e9s <strong>Noyaux<\/strong>.<\/li>\n<\/ul>\n\n<h2>Principes de base : ce qui se passe dans le noyau lors du trafic r\u00e9seau<\/h2>\n<p>Un paquet atterrit d'abord dans une interruption mat\u00e9rielle, puis le noyau prend le relais dans <strong>SoftIRQs<\/strong> et des boucles NAPI Poll. Je veille \u00e0 ce que la phase rapide de HardIRQ reste vraiment courte et que la logique proprement dite se d\u00e9place dans le bon contexte, afin que les <strong>temps CPU<\/strong> ne s'\u00e9vapore pas. Les threads ksoftirqd n'interviennent que lorsque le traitement direct n'est pas possible, ce qui conduit rapidement \u00e0 des files d'attente en cas de charge continue. C'est pr\u00e9cis\u00e9ment l\u00e0 que se produit le temps d'attente, qui se traduit par une augmentation du TTFB et un d\u00e9bit fluctuant. Pour ceux qui souhaitent aller plus loin, des connaissances pratiques sur le traitement des IRQ sont disponibles dans cet article sur <a href=\"https:\/\/webhosting.de\/fr\/gestion-des-interruptions-de-serveur-optimisation-des-performances-du-cpu-7342\/\">Gestion des interruptions et performances du CPU<\/a>, que j'utilise pour le classement.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/serverperformance-netzwerk-4861.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NAPI, SoftIRQs et ksoftirqd : contr\u00f4ler la latence au lieu de la g\u00e9rer<\/h2>\n<p>NAPI r\u00e9duit les temp\u00eates d'interruptions en r\u00e9cup\u00e9rant plusieurs paquets par passage dans un budget d\u00e9fini et en r\u00e9duisant ainsi <strong>Overhead<\/strong> diminue la qualit\u00e9 du service. Si le budget n'est pas suffisant, les paquets s'accumulent, ksoftirqd chauffe et les <strong>Latence<\/strong> augmente de mani\u00e8re mesurable. Dans de telles situations, je v\u00e9rifie syst\u00e9matiquement \/proc\/softirqs et \/proc\/net\/softnet_stat pour mettre en \u00e9vidence les drops, time_squeeze ou les files d'attente qui d\u00e9bordent. Ensuite, j'augmente progressivement net.core.netdev_budget ou net.core.netdev_budget_usecs et j'observe en parall\u00e8le la charge CPU, la r\u00e9partition p95\/p99 et les pertes de paquets. Tout l'art consiste \u00e0 effectuer suffisamment de travail par poll sans supplanter l'ex\u00e9cution interactive des threads userland.<\/p>\n\n<h2>\u00c9quilibrage IRQ et affinit\u00e9 : \u00e9viter les hotspots, augmenter les hits en cache<\/h2>\n<p>Un seul noyau avec toutes les IRQ de la carte r\u00e9seau devient un goulot d'\u00e9tranglement, car il doit servir \u00e0 la fois les interruptions, les IRQ logicielles et les threads d'applications ; je distribue donc <strong>IRQs<\/strong> de mani\u00e8re cibl\u00e9e. Le service irqbalance aide, mais pour les d\u00e9bits pps \u00e9lev\u00e9s, je mappe explicitement les queues RX\/TX par affinit\u00e9 sur des queues appropri\u00e9es. <strong>noyaux<\/strong>. Sur les syst\u00e8mes NUMA, je lie les files d'attente aux c\u0153urs du m\u00eame n\u0153ud afin d'\u00e9viter les acc\u00e8s \u00e0 la m\u00e9moire \u00e0 distance. Les threads d'application s'ex\u00e9cutent sur des c\u0153urs voisins mais s\u00e9par\u00e9s, ce qui am\u00e9liore la localit\u00e9 du cache et la pr\u00e9visibilit\u00e9. Un bon aper\u00e7u de la r\u00e9partition strat\u00e9gique est fourni par ce guide sur le <a href=\"https:\/\/webhosting.de\/fr\/serveur-irq-balancing-reseau-optimisation-des-performances-datacenter\/\">\u00c9quilibrage IRQ dans le centre de donn\u00e9es<\/a>, Je l'utilise comme r\u00e9f\u00e9rence pour les finitions.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/serverperformance3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Multi-files, RSS\/RPS\/XPS : bien utiliser la parall\u00e9lisation<\/h2>\n<p>Les NIC modernes apportent plusieurs files d'attente RX\/TX, que je peux g\u00e9rer par le biais de <strong>RSS<\/strong> sur les flux et obtenir ainsi un v\u00e9ritable parall\u00e9lisme. Si la carte n'offre pas assez de files d'attente, j'utilise le logiciel RPS\/XPS pour r\u00e9partir les paquets de mani\u00e8re judicieuse sur les flux. <strong>noyaux<\/strong> de pousser les flux. Il est important de r\u00e9partir proprement le hachage afin qu'un flux reste toujours sur la m\u00eame unit\u00e9 centrale et qu'il n'y ait pas de distorsions co\u00fbteuses du cache. En m\u00eame temps, je garde les chemins TX et RX proches les uns des autres afin d'\u00e9viter la contention et les acc\u00e8s cross-node inutiles. Ainsi, le d\u00e9bit pps augmente sans qu'un seul c\u0153ur ne freine.<\/p>\n\n<h2>L'affinit\u00e9 CPU jusque dans l'espace utilisateur : penser de bout en bout<\/h2>\n<p>Je planifie le chemin des donn\u00e9es depuis l'IRQ NIC jusqu'aux threads des travailleurs de l'application en passant par les files d'attente NAPI, afin que les paquets arrivent \u00e0 destination sans crochets inutiles et que les <strong>Temps de r\u00e9ponse<\/strong> reste constant. Pour cela, je s\u00e9pare syst\u00e9matiquement les noyaux pour les interruptions\/SoftIRQs des noyaux d'applications et je d\u00e9finis des r\u00e8gles claires pour les applications. <strong>Affinity<\/strong>-Les r\u00e8gles d'utilisation. Les serveurs web, les proxies invers\u00e9s et les bases de donn\u00e9es re\u00e7oivent des ensembles fixes de CPU, proches des noyaux IRQ, afin de r\u00e9duire les trajets. De plus, je place le CPU-Governor sur performance, afin que les changements d'horloge n'introduisent pas de gigue dans p99. Cette affectation coh\u00e9rente rend le comportement pr\u00e9visible et aide \u00e0 diagnostiquer proprement les goulots d'\u00e9tranglement.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/server-performance-optimization-8321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Offloads, GRO\/LRO, pare-feu et eBPF : \u00e9conomiser la charge sans voler \u00e0 l'aveuglette<\/h2>\n<p>\u00c9conomiser le checksum-offload, le TSO et le coalescing <strong>temps CPU<\/strong>, Mais ils peuvent modifier la taille des paquets, le comportement des bursts et la gigue, c'est pourquoi je mesure les effets de mani\u00e8re cibl\u00e9e. GRO\/LRO regroupe les trames et all\u00e8ge la pile, mais pour les exigences en temps r\u00e9el, je d\u00e9cide en fonction de la situation de <strong>D\u00e9sactivation<\/strong> ou une utilisation limit\u00e9e. Les tables Conntrack et les cha\u00eenes profondes de nftables\/iptables co\u00fbtent des mesures, je nettoie donc les r\u00e8gles superflues et simplifie les chemins. Si n\u00e9cessaire, j'ai recours \u00e0 eBPF (XDP, tc-BPF) pour prendre des d\u00e9cisions pr\u00e9coces au niveau de la carte r\u00e9seau et \u00e9viter les chemins co\u00fbteux. Un bon point de d\u00e9part pour la pratique du r\u00e9glage fin est cet aper\u00e7u de <a href=\"https:\/\/webhosting.de\/fr\/interrupt-coalescing-optimisation-du-reseau-serverflux\/\">Coalescence d'interruption<\/a>, Je tiens compte de ces \u00e9l\u00e9ments pour les budgets de latence sensibles.<\/p>\n\n<h2>Busy Polling et isolation du CPU : fixer les temps de r\u00e9action<\/h2>\n<p>Pour les objectifs de latence difficile, j'utilise le busy polling pour que les sockets userspace r\u00e9cup\u00e8rent les paquets encore plus t\u00f4t et <strong>Temps d'attente<\/strong> de temps. Cela augmente la charge, mais me donne des distributions p99 tr\u00e8s \u00e9troites pour les charges de travail API ou de trading sur des serveurs d\u00e9di\u00e9s. <strong>Noyaux<\/strong>. De plus, j'isole les c\u0153urs avec isolcpus=, nohz_full= et rcu_nocbs=, de sorte que les temporisateurs, RCU et services syst\u00e8me ne fonctionnent que sur les CPU de gardiennage. Cette s\u00e9paration emp\u00eache les perturbations sur les noyaux de latence et rend le comportement reproductible. En somme, il en r\u00e9sulte une feuille de route claire : des c\u0153urs d\u00e9di\u00e9s, une collecte pr\u00e9coce des paquets, des budgets d\u00e9finis.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/softirq_cpu_hosting_4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Surveillance et d\u00e9pannage : du sympt\u00f4me \u00e0 la cause<\/h2>\n<p>Je commence avec pps, d\u00e9bit et charge de base, puis je v\u00e9rifie les drops et l'activit\u00e9 des <strong>ksoftirqd<\/strong>-threads au fil du temps pour identifier avec certitude des mod\u00e8les. Des outils comme sar, htop, ss, nload et ethtool me montrent quand et o\u00f9 se forment les embouteillages et si les <strong>Queues de billard<\/strong> atteignent leurs limites. Il est important d'avoir des r\u00e9partitions plut\u00f4t que des moyennes, afin que les pics du soir, les fen\u00eatres Cron ou les campagnes ne soient pas noy\u00e9s. Je corr\u00e8le les pics TTFB avec la r\u00e9partition de l'IRQ, le budget NAPI et les param\u00e8tres de d\u00e9chargement afin d'agir de mani\u00e8re cibl\u00e9e sur les vis de r\u00e9glage. Souvent, il suffit d'adapter l'affinit\u00e9 IRQ ou de red\u00e9finir le budget NAPI pour r\u00e9duire sensiblement les temps morts.<\/p>\n\n<h2>Aper\u00e7u des param\u00e8tres de r\u00e9glage<\/h2>\n<p>L'aper\u00e7u suivant m'aide \u00e0 utiliser les modifications de mani\u00e8re r\u00e9fl\u00e9chie et \u00e0 attribuer clairement les effets avant de proc\u00e9der \u00e0 des modifications permanentes. <strong>d\u00e9ploiements<\/strong> planifie les choses. Je v\u00e9rifie chaque adaptation de mani\u00e8re it\u00e9rative, je mesure les distributions de latence et j'observe les effets secondaires sur <strong>CPU<\/strong> et de la m\u00e9moire. Je ne modifie qu'un point \u00e0 la fois par fen\u00eatre de test, afin que la cause et l'effet restent clairs. Ensuite, je documente les r\u00e9sultats et je d\u00e9finis des seuils d'alerte. J'obtiens ainsi des am\u00e9liorations reproductibles sans risquer de surprises dans le trafic productif.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Param\u00e8tre\/fonction<\/th>\n      <th>Effet dans le chemin de donn\u00e9es<\/th>\n      <th>Quand lever\/activer<\/th>\n      <th>Risques\/effets secondaires<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.netdev_budget<\/strong><\/td>\n      <td>Plus de paquets par poll NAPI<\/td>\n      <td>Pour les drops dans softnet_stat<\/td>\n      <td>Les sondages plus longs supplantent les fils de discussion des utilisateurs<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_budget_usecs<\/strong><\/td>\n      <td>Limiter la fen\u00eatre de temps par poll<\/td>\n      <td>En cas de gigue due \u00e0 de grandes salves<\/td>\n      <td>Trop petit : plus de changements de contexte<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>RSS\/RPS\/XPS<\/strong><\/td>\n      <td>R\u00e9partir les flux sur les noyaux<\/td>\n      <td>Pour les hotspots sur un noyau<\/td>\n      <td>Mauvais hashs : distorsions de la m\u00e9moire cache<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Affinit\u00e9 IRQ<\/strong><\/td>\n      <td>Lier les IRQ de mani\u00e8re cibl\u00e9e \u00e0 proximit\u00e9 du noyau<\/td>\n      <td>Chez NUMA-Missmatch<\/td>\n      <td>Une mauvaise affectation cr\u00e9e de nouvelles zones sensibles<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>GRO\/LRO\/TSO<\/strong><\/td>\n      <td>R\u00e9duit le nombre de paquets<\/td>\n      <td>En cas de bottleneck du CPU<\/td>\n      <td>Jitter, bursts plus importants<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Polling busy<\/strong><\/td>\n      <td>Collecte pr\u00e9coce des colis<\/td>\n      <td>Pour des cibles p99 difficiles<\/td>\n      <td>Consommation accrue du CPU<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/developer_desk_focus_optimization_3748.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Anneaux RX\/TX et profondeur de la file d'attente : bien dimensionner les tampons<\/h2>\n<p>M\u00eame avec des IRQ bien r\u00e9partis et des budgets adapt\u00e9s, des anneaux de carte r\u00e9seau trop petits ou trop grands peuvent faire baisser les performances. C'est pourquoi je v\u00e9rifie la taille des anneaux RX\/TX de la carte et les adapte au caract\u00e8re des bursts et aux objectifs de latence. Des anneaux trop petits entra\u00eenent des drops dans la carte r\u00e9seau lors des pics de trafic, visibles sous forme de rx_missed_errors ou fifo_errors dans les statistiques du pilote. Les anneaux trop grands masquent les congestions, augmentent la latence et g\u00e9n\u00e8rent de longues tra\u00een\u00e9es dans p95\/p99. Je cherche le juste milieu : assez de tampons pour absorber les courtes rafales, mais pas assez pour que les paquets \u201cvieillissent\u201d dans les files d'attente.<\/p>\n<p>En compl\u00e9ment, je consid\u00e8re le c\u00f4t\u00e9 h\u00f4te <strong>tx_queue_len<\/strong> et le Qdisc utilis\u00e9. Avec sch_fq ou fq_codel, je peux lisser le comportement des bursts et r\u00e9partir les gros paquets TSO via le pacing. Cela r\u00e9duit les micro-bursts au niveau du port de commutation et rend la courbe de latence plus calme - ce qui est important pour les charges de travail mixtes dans lesquelles de petits RPC sont ex\u00e9cut\u00e9s \u00e0 c\u00f4t\u00e9 de gros uploads. Ce faisant, j'observe les statistiques d'ethtool et je les corr\u00e8le avec softnet_stat pour voir si les congestions se produisent dans l'anneau NIC, dans le backlog netdev ou dans le Qdisc.<\/p>\n\n<h2>MTU, Jumbo Frames et segmentation<\/h2>\n<p>Le <strong>MTU<\/strong> est un levier classique qui est souvent sous-estim\u00e9. Les trames jumbo r\u00e9duisent le nombre de paquets par Gbit\/s et d\u00e9chargent l'unit\u00e9 centrale - mais uniquement si le chemin est vraiment compatible avec les trames jumbo de bout en bout. C'est pourquoi je valide syst\u00e9matiquement les contreparties, les commutateurs et les tunnels. D\u00e8s que l'on fragmente \u00e0 nouveau \u00e0 1500 quelque part, des probl\u00e8mes de MTU de chemin, des retransmissions et des co\u00fbts inutiles menacent. <strong>Jitter<\/strong>. Dans les centres de donn\u00e9es o\u00f9 les communications Est\/Ouest dominent, une strat\u00e9gie homog\u00e8ne 9k est rentable, tandis que pour les charges de travail Internet, 1500 est souvent le choix le plus stable.<\/p>\n<p>J'\u00e9value toujours le MTU en interaction avec <strong>TSO\/GSO\/GRO<\/strong>Un regroupement trop agressif peut conduire \u00e0 de grandes rafales dans le TX, qui remplissent les tampons en amont et g\u00e9n\u00e8rent des pics de latence. L'objectif est d'obtenir un chemin coh\u00e9rent : une segmentation judicieuse \u00e0 l'\u00e9metteur, des m\u00e9canismes de pacing suffisants et un GRO qui \u00e9conomise du travail du c\u00f4t\u00e9 du r\u00e9cepteur sans contrecarrer les exigences en temps r\u00e9el.<\/p>\n\n<h2>UDP, QUIC et charges de travail en streaming : tenir compte des sp\u00e9cificit\u00e9s<\/h2>\n<p>Tout le trafic n'est pas TCP. <strong>UDP<\/strong>-Les profils \u00e0 forte charge (DNS, VoIP, QUIC, t\u00e9l\u00e9m\u00e9trie) se comportent diff\u00e9remment dans RSS\/RPS et GRO. Les piles modernes supportent UDP-GRO\/GSO, ce qui peut soulager le CPU - je l'utilise de mani\u00e8re s\u00e9lective et je mesure si les risques de r\u00e9ordonnancement ou la gigue augmentent. Pour les charges QUIC\/HTTP3, une r\u00e9partition propre des flux est d\u00e9cisive : RPS peut aider si la carte r\u00e9seau n'offre pas assez de files d'attente RSS, mais ne doit pas \u201cbalancer\u201d des flux de cache \u00e0 chaud. C\u00f4t\u00e9 TX, je mets <strong>XPS<\/strong> afin de regrouper les chemins de transmission et de r\u00e9duire la contention. Dans la pratique, une affectation calme et affin\u00e9e au niveau du noyau est particuli\u00e8rement payante dans le cas de nombreux flux UDP de taille moyenne, pour lesquels chaque succ\u00e8s de la m\u00e9moire cache compte.<\/p>\n\n<h2>Virtualisation et conteneurs : int\u00e9grer proprement l'h\u00f4te, l'invit\u00e9 et le vhost<\/h2>\n<p>Dans les environnements virtualis\u00e9s, le travail se d\u00e9place entre l'h\u00f4te, les threads vhost et les IRQ invit\u00e9s. Je veille \u00e0 ce que <strong>vhost-net<\/strong>-Les threads doivent avoir leurs propres noyaux et ne pas entrer en collision avec les App-Works. Leurs affinit\u00e9s doivent correspondre aux files d'attente physiques RX\/TX, sinon il y a des migrations crois\u00e9es inutiles entre les processeurs. Dans l'invit\u00e9, je v\u00e9rifie les files d'attente virtio-net, j'active la multi-files d'attente et je configure RSS\/RPS de mani\u00e8re analogue au bare metal. L\u00e0 o\u00f9 la latence et le pps sont au premier plan, on peut <strong>SR-IOV<\/strong> r\u00e9duire encore l'overhead - \u00e0 condition que la topologie NUMA soit coh\u00e9rente : VF, vCPU et m\u00e9moire appartiennent au m\u00eame n\u0153ud.<\/p>\n<p>Dans la pile de conteneurs, les r\u00e9seaux superpos\u00e9s, les cha\u00eenes NAT profondes et les topologies CNI complexes provoquent des sauts suppl\u00e9mentaires. Pour les services critiques en termes de latence, je pr\u00e9f\u00e8re hostNetwork ou des r\u00e9seaux l\u00e9gers (macvlan\/ipvlan), j'\u00e9gare les chemins NAT et je garde <strong>Conntrack<\/strong> aussi petit que possible. Il est important d'avoir une strat\u00e9gie CPU coh\u00e9rente : les c\u0153urs IRQ et NAPI de l'h\u00f4te doivent se trouver \u00e0 proximit\u00e9 des c\u0153urs sur lesquels fonctionnent les travailleurs vhost\/container - c'est la seule fa\u00e7on de conserver un chemin de donn\u00e9es court et planifiable.<\/p>\n\n<h2>Ordonnancement, C-States et IRQ-Threading<\/h2>\n<p>Parce que la latence n'est pas seulement un temps de calcul, mais aussi un temps d'attente. <strong>Temps de r\u00e9veil<\/strong> je minimise les C-States profonds sur les noyaux de latence. Un powersave agressif peut co\u00fbter des millisecondes avant qu'une SoftIRQ ne soit r\u00e9ellement ex\u00e9cut\u00e9e. Je mise donc sur le gouverneur de performance, limite les C-States profonds et maintiens la coh\u00e9rence du turbo afin de rendre les sauts de fr\u00e9quence pr\u00e9visibles. Il est \u00e9galement important de <strong>Threading IRQ<\/strong>L\u00e0 o\u00f9 les pilotes le permettent, je d\u00e9place le travail dans les threads IRQ et j'attribue des priorit\u00e9s de telle sorte que RX d\u00e9marre avant le travail en aval, sans pour autant supplanter compl\u00e8tement Userland. L'interaction entre les politiques de planification, les affinit\u00e9s et les budgets est d\u00e9licate ; je teste par \u00e9tapes, j'enregistre p99 et je fais attention aux interf\u00e9rences avec ksoftirqd, qui devient sinon un goulot d'\u00e9tranglement secret.<\/p>\n\n<h2>Observation en profondeur : points de trace, compteurs, histos<\/h2>\n<p>Si les m\u00e9triques restent vagues, je descends d'un cran : j'utilise des points de trace du noyau autour de <strong>netif_receive_skb<\/strong>, <strong>napi_poll<\/strong> et <strong>net_dev_queue<\/strong>, pour voir les dur\u00e9es des polls, les quantit\u00e9s de paquets et les temps d'attente sous forme d'histogrammes. De telles distributions montrent si 1 % des polls durent trop longtemps ou si des files d'attente individuelles s'\u00e9chappent. En compl\u00e9ment, ethtool-<strong>rx\/tx<\/strong>-Counters, TCP Retransmits, Busy Poll Hits et softnet_stat indiquent clairement o\u00f9 les paquets sont perdus. Gr\u00e2ce \u00e0 l'analyse drop, je peux voir si la carte d'interface r\u00e9seau est en train d'abandonner (anneau plein), si le backlog netdev s'effondre (time_squeeze) ou si Qdisc\/Firewall freine. Ce n'est que lorsque ces pi\u00e8ces du puzzle s'assemblent que j'agis sur les anneaux, les budgets ou les offloads.<\/p>\n\n<h2>\u00c9purer les chemins de s\u00e9curit\u00e9 et de filtrage<\/h2>\n<p>Les ACL complexes, les cha\u00eenes profondes de nftables\/iptables et les larges tables de conntrack ajoutent une latence constante par paquet. Je consolide les r\u00e8gles, travaille avec des ensembles\/maps et d\u00e9place les drops g\u00e9n\u00e9riques le plus en amont possible dans le chemin - id\u00e9alement le plus t\u00f4t possible \u00e0 la NIC (XDP\/clsact) lorsque la latence est critique. Les flux sans \u00e9tat, la t\u00e9l\u00e9m\u00e9trie ou les ports \u201cs\u00fbrs\u201d connus peuvent \u00eatre utilis\u00e9s de mani\u00e8re cibl\u00e9e. <strong>sans suivi<\/strong> afin d'\u00e9viter les recherches co\u00fbteuses. En m\u00eame temps, je garde les tables d'\u00e9tat fra\u00eeches, j'adapte les tailles de hachage aux pics de charge et je nettoie agressivement les entr\u00e9es orphelines. L'objectif est d'obtenir un chemin de politique propre et compr\u00e9hensible, qui ne se manifeste pas dans le profil comme une charge permanente.<\/p>\n\n<h2>Les anti-mod\u00e8les typiques et comment je les \u00e9vite<\/h2>\n<ul>\n  <li><strong>Tous les IRQ sur un noyau :<\/strong> entra\u00eene une congestion et un ksoftirqd chaud. Antidote : affinit\u00e9s cibl\u00e9es par file d'attente, NUMA-coh\u00e9rent.<\/li>\n  <li><strong>Maximiser aveugl\u00e9ment les bagues\/budgets :<\/strong> masque la congestion, augmente les queues de latence. Antidote : augmenter de mani\u00e8re incr\u00e9mentielle, mesurer les distributions.<\/li>\n  <li><strong>Configuration de hachage de flux impr\u00e9cise :<\/strong> Les flux sautent entre les c\u0153urs, les caches s'\u00e9vaporent. Rem\u00e8de : cl\u00e9s RSS stables, RPS\/XPS uniquement avec un objectif clair.<\/li>\n  <li><strong>Threads d'applications sur les m\u00eames c\u0153urs que les SoftIRQ :<\/strong> Interf\u00e9rence et gigue. Contre-mesures : s\u00e9paration dure, affectation \u00e0 des voisins.<\/li>\n  <li><strong>Overlays\/NAT sans budget :<\/strong> s'ajoute \u00e0 chaque saut. Rem\u00e8de : all\u00e9ger les chemins, r\u00e9seaux proches de l'h\u00f4te pour les charges de travail \u00e0 latence.<\/li>\n  <li><strong>\u00c9conomie d'\u00e9nergie sur les noyaux de latence :<\/strong> les C-States profonds ralentissent la r\u00e9action. Antidote : gouverneur de performance, limitation des C-states.<\/li>\n  <li><strong>Offloads sans mesure :<\/strong> TSO\/GRO peuvent aggraver les bursts et la gigue. Antidote : activer de mani\u00e8re sp\u00e9cifique \u00e0 la charge de travail, observer p99.<\/li>\n<\/ul>\n\n<h2>Pratique de l'h\u00e9bergement : des \u00e9tapes qui font leur effet<\/h2>\n<p>Je commence par une phase de mesure propre, j'\u00e9tablis des lignes de base et je maintiens toutes les modifications \u00e0 un niveau faible dans des fen\u00eatres de temps courtes afin de pouvoir <strong>Causes<\/strong> peut s\u00e9parer. Ensuite, j'active irqbalance, je v\u00e9rifie la r\u00e9partition automatique et, si n\u00e9cessaire, je d\u00e9finis des affinit\u00e9s manuelles jusqu'\u00e0 ce qu'il n'y ait plus de <strong>Points chauds<\/strong> ne sont plus visibles. Ensuite, je mets en place la multi-queue, le RSS et - si n\u00e9cessaire - le RPS\/XPS, en accord avec NUMA. Je lie les app-workers \u00e0 des noyaux voisins de leurs noyaux IRQ, mais sans collision directe. Enfin, j'\u00e9pure les chemins de pare-feu, je v\u00e9rifie les tables de conntrack et je d\u00e9cide consciemment des offloads en fonction des objectifs de latence.<\/p>\n\n<h2>Exemple de playbook pour les latences p99<\/h2>\n<p>Tout d'abord, je mesure p95\/p99 via une charge repr\u00e9sentative et des logs s\u00e9curis\u00e9s \u00e0 partir de \/proc\/softirqs et \/proc\/net\/softnet_stat, afin de <strong>Drops<\/strong> et time_squeeze clairement. Ensuite, j'augmente pas \u00e0 pas netdev_budget ou netdev_budget_usecs et je garde p99 apr\u00e8s chaque changement, pour avoir de vrais <strong>Tendances<\/strong> de la m\u00eame mani\u00e8re. En parall\u00e8le, je lie les IRQ aux noyaux d'un n\u0153ud NUMA et je d\u00e9place les app-workers vers des voisins appropri\u00e9s. Si p99 continue \u00e0 sauter, je teste des variantes GRO\/LRO et des profils de coalescence d'interruption, \u00e0 chaque fois avec une courte distance de mesure. Ce n'est que lorsque la distribution reste calme que je transf\u00e8re la configuration dans des r\u00f4les Ansible ou des dropins systemd.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/serverraum-performance-1947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>R\u00e9sum\u00e9 pour les admins<\/h2>\n<p>J'obtiens le plus grand effet de levier en <strong>SoftIRQs<\/strong>, Je consid\u00e8re le budget NAPI, les affinit\u00e9s IRQ et les threads d'applications comme un chemin de donn\u00e9es coh\u00e9rent. Je r\u00e9partis le travail en r\u00e9seau sur les noyaux, je maintiens des files d'attente coh\u00e9rentes NUMA et je lie les travailleurs de mani\u00e8re judicieuse afin que <strong>Parcours<\/strong> rester court. Je place les offloads de mani\u00e8re consciente et je mesure la gigue au lieu d'optimiser aveugl\u00e9ment le d\u00e9bit. Pour les objectifs de latence difficiles, je mise sur le busy polling et l'isolation du CPU, tandis que les CPU housekeeping interceptent les tirs parasites. En appliquant ces \u00e9tapes de mani\u00e8re disciplin\u00e9e, on obtient un d\u00e9bit constant, des r\u00e9partitions de latence plus \u00e9troites et un environnement d'h\u00e9bergement qui r\u00e9agit de mani\u00e8re pr\u00e9visible aux pics de charge.<\/p>","protected":false},"excerpt":{"rendered":"<p>Apprends comment softirq cpu hosting augmente le d\u00e9bit de ton r\u00e9seau et r\u00e9duit les latences dans le fonctionnement du serveur gr\u00e2ce \u00e0 des interruptions linux optimis\u00e9es, NAPI et IRQ-Balancing.<\/p>","protected":false},"author":1,"featured_media":19562,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19569","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"70","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"softirq cpu","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19562","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19569","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=19569"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19569\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/19562"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=19569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=19569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=19569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}