{"id":19745,"date":"2026-06-06T15:03:33","date_gmt":"2026-06-06T13:03:33","guid":{"rendered":"https:\/\/webhosting.de\/server-irq-affinity-multicore-netzwerkoptimierung-performance\/"},"modified":"2026-06-06T15:03:33","modified_gmt":"2026-06-06T13:03:33","slug":"serveur-irq-affinity-multicore-optimisation-du-reseau-performance","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/server-irq-affinity-multicore-netzwerkoptimierung-performance\/","title":{"rendered":"Server IRQ Affinity et optimisation du r\u00e9seau multi-c\u0153ur pour une performance maximale"},"content":{"rendered":"<p>J'optimise les chemins d'acc\u00e8s au r\u00e9seau d'un serveur en <strong>IRQ Affinity<\/strong> de mapper les files d'attente RX\/TX sur les c\u0153urs et de contr\u00f4ler ainsi la latence, le d\u00e9bit et la gigue p99. Celui qui utilise les processeurs multic\u0153urs de mani\u00e8re cons\u00e9quente, orchestre les interruptions, les SoftIRQs, NAPI et NUMA de mani\u00e8re \u00e0 ce que les flux restent affin\u00e9s au niveau du noyau, que les changements de contexte diminuent et que l'application r\u00e9agisse de mani\u00e8re mesurable plus rapidement.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>Distribution de l'IRQ<\/strong> d\u00e9termine quels noyaux portent des interruptions mat\u00e9rielles et \u00e9vite les zones sensibles.<\/li>\n  <li><strong>Proximit\u00e9 du NUMA<\/strong> r\u00e9duit les acc\u00e8s \u00e0 distance et diminue les pics de latence.<\/li>\n  <li><strong>SoftIRQs &amp; NAPI<\/strong> contr\u00f4lent le traitement par lots et d\u00e9chargent les noyaux.<\/li>\n  <li><strong>RPS\/RFS<\/strong> maintient les flux proches des fils de consommation.<\/li>\n  <li><strong>Mesure &amp; \u00e9pinglage<\/strong> rend la performance plus d\u00e9terministe.<\/li>\n<\/ul>\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\/serverraum-optimierung-4761.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pourquoi IRQ Affinity compte dans le fonctionnement du serveur<\/h2>\n\n<p>Des d\u00e9bits de paquets \u00e9lev\u00e9s surchargent rapidement certains c\u0153urs lorsque toutes les interruptions atterrissent sur quelques CPU, c'est pourquoi je r\u00e9partis la charge de mani\u00e8re cibl\u00e9e pour <strong>Points chauds<\/strong> d'\u00e9viter les probl\u00e8mes. J'attribue les queues RX\/TX aux c\u0153urs appropri\u00e9s afin que les chemins de donn\u00e9es restent courts et que les caches restent chauds. Ainsi, les latences p95\/p99 diminuent, car j'\u00e9vite les migrations inutiles et je conserve les \u00e9tapes de traitement sur les m\u00eames c\u0153urs. Je tiens compte de la proximit\u00e9 physique de la carte r\u00e9seau, des canaux de m\u00e9moire et des socles de l'unit\u00e9 centrale afin que le chemin du paquet jusqu'\u00e0 l'Application-Worker reste constamment rapide. Cette affinit\u00e9 du noyau cr\u00e9e une stabilit\u00e9 mesurable en cas de pics de trafic, sans devoir mettre imm\u00e9diatement \u00e0 niveau le mat\u00e9riel.<\/p>\n\n<h2>\u00c9quilibrage IRQ vs. affinit\u00e9 fixe<\/h2>\n\n<p>Le service standard <strong>irqbalance<\/strong> distribue automatiquement les interruptions, mais il ne conna\u00eet pas la logique de mon application, les objectifs NUMA et les budgets de latence. Je fixe les IRQ r\u00e9seau critiques sur des c\u0153urs s\u00e9lectionn\u00e9s, tandis que les interruptions bruyantes ou moins importantes se d\u00e9placent vers d'autres c\u0153urs. Ce lien s'harmonise avec l'\u00e9pinglage des processus d'application, de sorte que le pipeline reste coh\u00e9rent par flux. En cas de fort trafic, j'\u00e9vite ainsi les redistributions qui g\u00e9n\u00e8rent des surcharges suppl\u00e9mentaires et affaiblissent l'effet de cache. Si vous souhaitez aller plus loin, vous trouverez des informations pratiques dans ce guide : <a href=\"https:\/\/webhosting.de\/fr\/serveur-irq-balancing-reseau-optimisation-des-performances-datacenter\/\">\u00c9quilibrage IRQ dans le centre de donn\u00e9es<\/a>.<\/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\/netzwerkoptimierung_meeting_4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Affinit\u00e9 CPU, NUMA et le chemin de donn\u00e9es court<\/h2>\n\n<p>J'\u00e9pingle de pr\u00e9f\u00e9rence les Application-Worker et les IRQ de r\u00e9seau sur le m\u00eame <strong>NUMA<\/strong>-pour que l'acc\u00e8s \u00e0 la m\u00e9moire reste local. Si une carte r\u00e9seau d\u00e9pend du n\u0153ud 0, je place \u00e9galement les queues RX correspondantes \u00e0 cet endroit et je lie les processus pertinents \u00e0 ces noyaux. J'\u00e9vite ainsi les acc\u00e8s \u00e0 la m\u00e9moire \u00e0 distance co\u00fbteux qui ont un impact important sur la latence lorsque les taux de paquets sont \u00e9lev\u00e9s. J'int\u00e8gre \u00e9galement des paires d'hyperthreading afin que les threads fr\u00e8res ne se perturbent pas mutuellement. Ce triangle form\u00e9 par l'\u00e9pinglage des processus, l'affinit\u00e9 IRQ et la topologie NUMA rend les chemins du r\u00e9seau plus pr\u00e9visibles et augmente le d\u00e9bit.<\/p>\n\n<h2>Comprendre les SoftIRQs, NAPI et la conception des files d'attente<\/h2>\n\n<p>Apr\u00e8s l'interruption mat\u00e9rielle, le noyau prend en charge le traitement en <strong>SoftIRQs<\/strong>, souvent sur le m\u00eame noyau que celui qui a re\u00e7u l'IRQ. En cas de charge \u00e9lev\u00e9e, je r\u00e9partis volontairement la charge de l'IRQ logiciel afin de d\u00e9samorcer les goulets d'\u00e9tranglement sans fragmenter inutilement le chemin de donn\u00e9es. Les NIC multi-queues m'aident, car je peux attribuer \u00e0 chaque file des c\u0153urs clairement d\u00e9finis et obtenir ainsi une v\u00e9ritable parall\u00e9lisation. Gr\u00e2ce \u00e0 NAPI, je traite les paquets par lots afin d'\u00e9viter les temp\u00eates d'interruptions et d'utiliser efficacement le temps de l'unit\u00e9 centrale. Cet article me fournit des informations de fond sur ce chemin : <a href=\"https:\/\/webhosting.de\/fr\/softirq-cpu-hosting-optimisation-du-debit-reseau-datacenter\/\">SoftIRQ et d\u00e9bit r\u00e9seau<\/a>.<\/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\/maxperformance-network-optimization-6742.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>RPS\/RFS et localit\u00e9 du flux<\/h2>\n\n<p>J'utilise RPS pour une distribution plus large des paquets et je mets <strong>RFS<\/strong> pour que les flux arrivent aux threads qui les consomment. Ainsi, les acc\u00e8s au cache restent efficaces et l'application b\u00e9n\u00e9ficie de temps de r\u00e9ponse coh\u00e9rents. J'harmonise la strat\u00e9gie de hachage de la carte r\u00e9seau, le nombre de files d'attente et les ensembles RPS-CPU afin qu'aucune file d'attente du noyau ne d\u00e9borde. L'affinit\u00e9 de flux agit surtout en cas de nombreuses requ\u00eates courtes, comme celles g\u00e9n\u00e9r\u00e9es par les API et les microservices. Je construis ainsi un pipeline dans lequel chaque flux touche le plus souvent possible le m\u00eame noyau et \u00e9vite les migrations inutiles.<\/p>\n\n<h2>RSS, table d'indirection et XPS : contr\u00f4ler le hachage de mani\u00e8re cibl\u00e9e<\/h2>\n\n<p>Pour que la distribution commence proprement \u00e0 la carte r\u00e9seau, je r\u00e8gle <strong>RSS<\/strong> (Receive Side Scaling) et la table d'indirection de mani\u00e8re \u00e0 ce que les queues RX soient affect\u00e9es exactement aux c\u0153urs qui porteront plus tard les threads de l'application. Je veille \u00e0 ce que le nombre de files d'attente corresponde au nombre de c\u0153urs utilis\u00e9s et que les cl\u00e9s de hachage restent stables afin que les flux ne se d\u00e9placent pas de mani\u00e8re inattendue. Si l'algorithme de hachage change ou si la table d'indirection est \u00e9cras\u00e9e de mani\u00e8re dynamique, cela d\u00e9chire sinon la localit\u00e9 du flux et favorise les \u00e9checs de cache.<\/p>\n\n<p>Sur le chemin TX, j'active en plus <strong>XPS<\/strong> (Transmit Packet Steering), afin que les paquets sortants soient envoy\u00e9s par le noyau qui traite l'application. De cette mani\u00e8re, les caches TX restent proches du travailleur et le chemin de la file d'attente des sockets \u00e0 la file d'attente de la carte r\u00e9seau reste court. Je garde les affectations RX et TX coh\u00e9rentes, je les documente par interface et je les d\u00e9finis dans les scripts de d\u00e9marrage afin qu'un red\u00e9marrage ne brouille pas l'architecture.<\/p>\n\n<h2>Interrupt Coalescing : mettre en balance la latence et le d\u00e9bit<\/h2>\n\n<p>Avec <strong>Coalescence<\/strong> je regroupe les interruptions pour r\u00e9duire les frais g\u00e9n\u00e9raux, mais je fais attention aux limites de latence de mon application. Pour le streaming et la VoIP, je laisse les intervalles plut\u00f4t courts, alors que les transferts en vrac supportent bien des lots plus longs. Je teste par \u00e9tapes, mesure p95\/p99 et v\u00e9rifie les drops, les retransmissions ainsi que l'utilisation du CPU par noyau. Ce n'est qu'ensuite que je fixe les param\u00e8tres et que je les documente par h\u00f4te et par carte r\u00e9seau. Cet article pratique propose une approche plus approfondie du trade-off : <a href=\"https:\/\/webhosting.de\/fr\/interrupt-coalescing-optimisation-du-reseau-serverflux\/\">Interrupt Coalescing expliqu\u00e9<\/a>.<\/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\/tech_office_multi_core_optimierung_4729.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bien doser les offloads et l'agr\u00e9gation<\/h2>\n\n<p>Je mets <strong>GRO\/LRO<\/strong> pour r\u00e9duire l'overhead CPU, mais je v\u00e9rifie si mes charges de travail b\u00e9n\u00e9ficient de lots plus importants. Les API sensibles \u00e0 la latence r\u00e9agissent souvent mieux lorsque GRO est mod\u00e9r\u00e9 et LRO d\u00e9sactiv\u00e9, car les gros super-paquets peuvent aggraver les effets de blocage en t\u00eate de ligne. Pour les transferts en vrac, la r\u00e9plication ou les sauvegardes, j'utilise GRO\/GSO\/TSO de mani\u00e8re plus agressive, tant que le c\u00f4t\u00e9 r\u00e9cepteur reste stable et que l'utilisation du CPU diminue.<\/p>\n\n<p><strong>T\u00e9l\u00e9chargements de checksum<\/strong> et <strong>TSO\/GSO<\/strong> d\u00e9chargent consid\u00e9rablement le CPU, mais je m'assure que les middleboxes, les tunnels ou les incompatibilit\u00e9s de d\u00e9chargement (par exemple pour certaines encapsulations) fonctionnent correctement. Si des anomalies apparaissent, je r\u00e9duis progressivement certains offloads et je mesure les effets sur le d\u00e9bit, les retransmissions et le temps CPU. L'objectif est d'obtenir un ensemble qui reste stable en largeur et pr\u00e9visible en pointe.<\/p>\n\n<h2>Isolation du CPU, ordonnanceur et \u00e9tats d'\u00e9nergie<\/h2>\n\n<p>Pour les budgets de latence difficiles, j'isole des noyaux pour les chemins de r\u00e9seau et les app-workers. Avec <strong>Isolation du CPU<\/strong> et une strat\u00e9gie de housekeeping all\u00e9g\u00e9e, j'\u00e9vite que les t\u00e2ches syst\u00e8me, les Kthreads ou les interruptions de timer ne se retrouvent sur les c\u0153urs \u201echauds\u201c. En outre, je fixe le <strong>Gouverneur de l'unit\u00e9 centrale<\/strong> sur \u201eperformance\u201c et limite la profondeur <strong>\u00c9tats C<\/strong>, Je ne veux pas que cela provoque des latences de r\u00e9veil. Je garde un \u0153il sur les temp\u00e9ratures \u00e0 c\u0153ur, car la pourriture thermique peut sinon r\u00e9duire \u00e0 n\u00e9ant toute finition.<\/p>\n\n<p>Le choix de la <strong>Classes d'ordonnancement<\/strong> affecte la pr\u00e9dictibilit\u00e9. Je laisse les threads proches du r\u00e9seau s'ex\u00e9cuter en priorit\u00e9, mais sans exclusivit\u00e9 agressive, afin qu'ils ne soient pas en concurrence avec ksoftirqd pour le temps CPU. Je v\u00e9rifie r\u00e9guli\u00e8rement si ksoftirqd s'active sur certains c\u0153urs - un signe clair que la charge de SoftIRQ est trop \u00e9lev\u00e9e ou mal r\u00e9partie.<\/p>\n\n<h2>Busy-polling et chemins \u00e0 faible latence<\/h2>\n\n<p>Quand les microsecondes comptent, je mets <strong>Busy-Polling<\/strong> de mani\u00e8re cibl\u00e9e. Les applications peuvent d\u00e9finir des fen\u00eatres d'interrogation pour des sockets s\u00e9lectionn\u00e9s, de sorte qu'elles tirent des paquets directement des budgets NAPI sans attendre les interruptions. Je choisis des intervalles de poll courts pour ne pas br\u00fbler le temps de l'unit\u00e9 centrale et je limite cette technique aux hot paths avec un trafic constant. En parall\u00e8le, j'adapte <strong>Budgets netdev<\/strong> mod\u00e9r\u00e9ment, afin que les lots soient suffisamment grands sans affamer le reste du syst\u00e8me.<\/p>\n\n<h2>Discipline de la file d'attente r\u00e9seau et pacing<\/h2>\n\n<p>Je mets en place <strong>qdisc<\/strong> par interface en fonction de la charge de travail. Avec des disciplines modernes comme fq\/fq_codel, je r\u00e9gule le pacing et la longueur des files d'attente pour lisser les bursts et \u00e9viter le bufferbloat. Dans les configurations multi-queues, je combine cela avec <strong>mqprio<\/strong>, pour que les classes de trafic restent affect\u00e9es de mani\u00e8re coh\u00e9rente aux bonnes files d'attente HW. Avec <strong>BQL<\/strong> (Byte Queue Limits) sur le pilote permet de r\u00e9duire les latences \u00e0 pleine charge, car la file d'attente n'augmente pas de mani\u00e8re incontr\u00f4l\u00e9e.<\/p>\n\n<p>L'important, c'est l'interaction avec <strong>XPS<\/strong> sur le chemin TX : Je mappe les files d'attente d'envoi aux c\u0153urs sur lesquels atterrissent \u00e9galement les flux RX correspondants. Ainsi, les deux directions d'un flux restent proches de l'unit\u00e9 centrale et j'obtiens des temps de r\u00e9ponse plus stables avec les protocoles bidirectionnels (par ex. HTTP\/2, gRPC).<\/p>\n\n<h2>Flux de travail du cabinet sous Linux<\/h2>\n\n<p>Je commence par une prise de charge, je v\u00e9rifie la r\u00e9partition du CPU dans top\/htop, je regarde \/proc\/interrupts et \/proc\/softirqs et je lis les statistiques d'ethtool pour identifier les goulots d'\u00e9tranglement et pr\u00e9parer le prochain <strong>Flux de travail<\/strong>-\u00e0 l'\u00e9tape suivante. Ensuite, je d\u00e9termine les IRQ-ID des queues NIC pertinentes et je d\u00e9finis des masques CPU appropri\u00e9s qui occupent les c\u0153urs de mani\u00e8re \u00e9gale et qui tiennent compte de NUMA. Ensuite, j'\u00e9pingle les Application-Worker par taskset ou systemd-CPUAffinity sur les m\u00eames noyaux que ceux qui servent les files d'attente correspondantes. Je n'active RPS\/RFS que l\u00e0 o\u00f9 il renforce la localit\u00e9 du flux et je garde la configuration coh\u00e9rente par interface. Enfin, je mesure \u00e0 nouveau le d\u00e9bit, la latence et la gigue avant de d\u00e9ployer les modifications de mani\u00e8re uniforme sur plusieurs h\u00f4tes.<\/p>\n\n<h2>\u00c9viter la mesure, p95\/p99 et les r\u00e9gressions<\/h2>\n\n<p>Je ne me fie pas \u00e0 mon instinct, mais je mesure les latences, les taux d'erreur et l'utilisation des c\u0153urs avant et apr\u00e8s chaque session de r\u00e9glage, afin que <strong>p99<\/strong> reste stable. En outre, j'effectue un suivi des changements de contexte, des taux de migration et de la charge par type de SoftIRQ afin de d\u00e9tecter rapidement les effets secondaires cach\u00e9s. J'assure la reproductibilit\u00e9 des tests, j'utilise des ensembles de donn\u00e9es identiques et des versions fixes pour que les r\u00e9sultats restent comparables. Je d\u00e9masque les r\u00e9gressions \u00e0 l'aide de tests crois\u00e9s dans des conditions de pic et d'inactivit\u00e9, ainsi qu'avec de longs tests d'endurance. Ce n'est que lorsque les m\u00e9triques, les logs et les traces d'application concordent que je d\u00e9clare la configuration comme nouvelle situation de r\u00e9f\u00e9rence.<\/p>\n\n<h2>Virtualisation, conteneurs et SR-IOV<\/h2>\n\n<p>Dans les environnements virtualis\u00e9s, je veille \u00e0 ce que <strong>vCPU<\/strong>, J'ai choisi de placer la m\u00e9moire et les vNIC de la VM sur le m\u00eame n\u0153ud NUMA que la NIC physique correspondante. Dans la mesure du possible, j'utilise <strong>SR-IOV<\/strong>, Je fais en sorte que le chemin de donn\u00e9es soit court et que les IRQ soient directement li\u00e9es aux noyaux invit\u00e9s. J'\u00e9pingle les vCPU des machines virtuelles critiques sur des noyaux h\u00f4tes d\u00e9di\u00e9s et je veille \u00e0 ce que les IRQ h\u00f4tes et les IRQ invit\u00e9s ne se chevauchent pas. Dans les configurations de conteneurs, je place <strong>cpusets<\/strong> et des classes de qualit\u00e9 de service \u201egaranties\u201c, afin que les conteneurs de travail et leurs IRQ r\u00e9seau obtiennent du temps d'unit\u00e9 centrale de mani\u00e8re planifiable.<\/p>\n\n<p>Je v\u00e9rifie si irqbalance doit \u00eatre le chef de file dans l'invit\u00e9 ou sur l'h\u00f4te - un double \u201eautomatisme\u201c produit sinon des impr\u00e9cisions. Avec virtio, je d\u00e9finis plusieurs files d'attente et les mappe proprement sur les vCPU afin de permettre le travail en parall\u00e8le. Si vhost-net charge certains c\u0153urs d'h\u00f4tes, je redistribue les backends et garde les threads vhost proches de la NUMA de la carte r\u00e9seau physique.<\/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\/servernetzwerkoptmierung-9473.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>D\u00e9pistage des erreurs : identifier rapidement les mod\u00e8les<\/h2>\n\n<ul>\n  <li><strong>Noyaux satur\u00e9s, ksoftirqd actifs :<\/strong> \u00c9pingler plus \u00e9troitement les queues RX, v\u00e9rifier le nombre de queues, adapter RPS\/RFS ou augmenter l\u00e9g\u00e8rement le coalescing.<\/li>\n  <li><strong>Instabilit\u00e9 de p99 :<\/strong> V\u00e9rifier la d\u00e9rive NUMA, v\u00e9rifier les C-States\/Governor, ajuster progressivement les offloads et les tailles GRO.<\/li>\n  <li><strong>Beaucoup de retransmissions\/drops :<\/strong> Contr\u00f4ler les tailles d'anneau RX\/TX, qdisc et BQL, v\u00e9rifier la coh\u00e9rence de la table d'indirection et du XPS.<\/li>\n  <li><strong>Flux in\u00e9galement r\u00e9partis :<\/strong> \u00c9quilibrer le hash RSS et la table d'indirection, envisager l'\u00e9pinglage \u00e0 chaud, maintenir la stabilit\u00e9 du hash seed.<\/li>\n  <li><strong>Probl\u00e8me de VM seule :<\/strong> Placer les backends vhost\/virtio \u00e0 proximit\u00e9 de NUMA, \u00e9valuer SR-IOV, d\u00e9senchev\u00eatrer les IRQ entre h\u00f4te et invit\u00e9.<\/li>\n<\/ul>\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\/entwicklerschreibtisch_4312.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Int\u00e9grer les applications et les bases de donn\u00e9es<\/h2>\n\n<p>Un chemin r\u00e9seau propre ne sert pas \u00e0 grand-chose si les serveurs d'apps ou les bases de donn\u00e9es ne fonctionnent pas en parall\u00e8le, c'est pourquoi je configure les <strong>Travailleur<\/strong>-Le nombre de threads, les pools de threads et les limites de connexion sont d\u00e9finis sur les c\u0153urs disponibles. J'\u00e9pingle les workers NGINX ou HAProxy sur les c\u0153urs appropri\u00e9s pour qu'ils correspondent aux files d'attente RX. Je mets \u00e0 l'\u00e9chelle PHP-FPM, Node.js, Java ou Go de mani\u00e8re \u00e0 ce qu'ils privil\u00e9gient le domaine NUMA local et utilisent plusieurs instances si n\u00e9cessaire. J'int\u00e8gre les caches comme Redis ou Memcached \u00e0 proximit\u00e9 du CPU et je fais attention \u00e0 leurs propres param\u00e8tres de r\u00e9seau et de thread. Ce n'est qu'en combinant l'affinit\u00e9 IRQ, l'\u00e9pinglage des processus et la mise \u00e0 l'\u00e9chelle des applications que l'on obtient une am\u00e9lioration sensible de la latence et du d\u00e9bit.<\/p>\n\n<h2>Des sc\u00e9narios d'h\u00e9bergement \u00e0 forte valeur ajout\u00e9e<\/h2>\n\n<p>J'investis surtout dans le tuning profond lorsque les API g\u00e9n\u00e8rent un grand nombre de requ\u00eates courtes ou lorsque <strong>Temps r\u00e9el<\/strong>-comme la VoIP et les chats exigent de faibles valeurs de gigue. Les configurations de commerce \u00e9lectronique avec des pics de charge en profitent, car les flux de sortie sont sensibles \u00e0 la latence. Les h\u00f4tes multi-locataires \u00e0 haute densit\u00e9 sont gagnants, car les c\u0153urs d\u00e9di\u00e9s par file d'attente r\u00e9duisent les effets de voisinage. Les services de streaming peuvent \u00e9galement obtenir plus de d\u00e9bit par euro sans devoir acheter imm\u00e9diatement du nouveau mat\u00e9riel. Les co\u00fbts restent pr\u00e9visibles tant que je garde les changements mesurables et que je les d\u00e9ploie de mani\u00e8re cibl\u00e9e.<\/p>\n\n<h2>Tableau de r\u00e9f\u00e9rence rapide : noyaux, files d'attente, outils<\/h2>\n\n<p>J'utilise la suivante <strong>Tableau<\/strong> comme aide-m\u00e9moire lorsque je configure de nouveaux h\u00f4tes ou recalibre des configurations existantes. Elle montre des objectifs typiques, des mesures appropri\u00e9es, des outils Linux courants et l'effet pr\u00e9vu sur la latence et le d\u00e9bit. Je ne l'utilise pas de mani\u00e8re dogmatique, mais comme point de d\u00e9part pour des s\u00e9ries de mesures avec du trafic r\u00e9el. Si l'architecture de la carte r\u00e9seau ou la topologie NUMA varie, j'adapte la s\u00e9lection de base. Il est important de conserver la documentation pour chaque h\u00f4te et d'assurer la tra\u00e7abilit\u00e9 des modifications.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Objectif<\/th>\n      <th>Mesure<\/th>\n      <th>Outil\/lieu Linux<\/th>\n      <th>Effet attendu<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>R\u00e9partir la charge de l'IRQ<\/td>\n      <td>Lier les queues aux noyaux<\/td>\n      <td>\/proc\/irq\/*\/smp_affinity<\/td>\n      <td>Moins de points chauds, latence plus constante<\/td>\n    <\/tr>\n    <tr>\n      <td>Augmenter la localit\u00e9 du flux<\/td>\n      <td>D\u00e9finir les ensembles RPS\/RFS CPU<\/td>\n      <td>\/sys\/class\/net\/*\/queues\/*\/rps_cpus<\/td>\n      <td>Moins de migrations, de meilleurs caches<\/td>\n    <\/tr>\n    <tr>\n      <td>Contr\u00f4ler le traitement par lots<\/td>\n      <td>Ajuster finement NAPI\/Coalescing<\/td>\n      <td>ethtool -C \/ D\u00e9fauts du pilote<\/td>\n      <td>Moins d'overhead, gigue contr\u00f4l\u00e9e<\/td>\n    <\/tr>\n    <tr>\n      <td>Coupler l'application et l'IRQ<\/td>\n      <td>\u00c9pingler un travailleur<\/td>\n      <td>taskset, systemd CPUAffinity<\/td>\n      <td>Chemin plus court, p99 plus faible<\/td>\n    <\/tr>\n    <tr>\n      <td>\u00c9viter la NUMA<\/td>\n      <td>Co-localiser les appareils et les noyaux<\/td>\n      <td>numactl, lscpu, lspci -vv<\/td>\n      <td>Moins d'acc\u00e8s \u00e0 distance, plus de d\u00e9bit<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Des bonnes pratiques qui portent leurs fruits \u00e0 long terme<\/h2>\n\n<p>Je ne modifie qu'un seul levier de r\u00e9glage par tour de test, je documente les m\u00e9triques et je s\u00e9curise les <strong>Documentation<\/strong> dans le repo de l'h\u00f4te. Je garde les configurations coh\u00e9rentes en d\u00e9crivant clairement les affectations de file d'attente \u00e0 c\u0153ur et en utilisant des scripts pour la r\u00e9plication. J'observe les logs pour les drops, les retransmissions et les timeouts et je les corr\u00e8le avec les m\u00e9triques du noyau. J'int\u00e8gre les niveaux de l'hyperviseur et du stockage dans l'analyse afin qu'il ne reste pas de goulots d'\u00e9tranglement. Je tiens les rollbacks \u00e0 disposition si les tests montrent des effets n\u00e9gatifs ou si les charges de travail changent.<\/p>\n\n<h2>En bref<\/h2>\n\n<p>J'obtiens une performance maximale du r\u00e9seau en utilisant des interruptions, <strong>Queues de billard<\/strong> et Worker, ce qui permet de maintenir la stabilit\u00e9 du chemin de donn\u00e9es par flux. IRQ Affinity r\u00e9partit judicieusement la charge mat\u00e9rielle, tandis que SoftIRQs, NAPI et RPS\/RFS rendent le traitement efficace. La proximit\u00e9 de NUMA prot\u00e8ge contre les d\u00e9tours de m\u00e9moire \u00e9vitables et r\u00e9duit la gigue. Un r\u00e9glage progressif avec des mesures reproductibles \u00e9vite les configurations erron\u00e9es et montre de r\u00e9els progr\u00e8s. Celui qui pense ces \u00e9l\u00e9ments ensemble exploite souverainement les capacit\u00e9s des serveurs multic\u0153urs modernes pour les services critiques en termes de latence.<\/p>","protected":false},"excerpt":{"rendered":"<p>D\u00e9couvre comment Server IRQ Affinity et l'optimisation du r\u00e9seau multicore acc\u00e9l\u00e8rent ton traitement de paquets et exploitent au maximum le r\u00e9seau multicore dans l'h\u00e9bergement.<\/p>","protected":false},"author":1,"featured_media":19738,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19745","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":"111","_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":"IRQ Affinity","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":"19738","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19745","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=19745"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19745\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/19738"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=19745"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=19745"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=19745"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}