{"id":18713,"date":"2026-04-04T15:03:28","date_gmt":"2026-04-04T13:03:28","guid":{"rendered":"https:\/\/webhosting.de\/server-interrupt-handling-cpu-performance-optimization-7342\/"},"modified":"2026-04-04T15:03:28","modified_gmt":"2026-04-04T13:03:28","slug":"gestion-des-interruptions-de-serveur-optimisation-des-performances-du-cpu-7342","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/server-interrupt-handling-cpu-performance-optimization-7342\/","title":{"rendered":"Gestion des interruptions sur les serveurs : comment les interruptions du CPU influencent les performances"},"content":{"rendered":"<p>Les interruptions CPU contr\u00f4lent la vitesse \u00e0 laquelle mon serveur r\u00e9agit aux paquets r\u00e9seau, aux \u00e9v\u00e9nements de stockage et aux temporisateurs - des interruptions mal r\u00e9parties ou trop fr\u00e9quentes ralentissent les applications de mani\u00e8re mesurable. Un serveur de gestion des interruptions propre r\u00e9duit les changements de contexte, diminue les latences et stabilise les temps de r\u00e9ponse lors des pics de charge.<\/p>\n\n<h2>Points centraux<\/h2>\n<p>Je r\u00e9sume de mani\u00e8re compacte les aspects cl\u00e9s suivants avant d'entrer dans les d\u00e9tails :<\/p>\n<ul>\n  <li><strong>Charge d'interruption<\/strong> comprendre : A partir de quand les pourcentages deviennent critiques<\/li>\n  <li><strong>Parall\u00e9lisme<\/strong> g\u00e9rer les interruptions simultan\u00e9es et les pires cas de latence<\/li>\n  <li><strong>MSI-X<\/strong> utiliser les informations : Plus de messages, meilleure distribution<\/li>\n  <li><strong>RSS<\/strong> &amp; Affinit\u00e9 : placer les interruptions NIC sur les noyaux<\/li>\n  <li><strong>Suivi<\/strong> s'\u00e9tablissent : Lire les chiffres, agir de mani\u00e8re cibl\u00e9e<\/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\/04\/server-performance-4561.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ce que les interruptions du CPU d\u00e9clenchent sur les serveurs<\/h2>\n\n<p>Une interruption est un <strong>Signal<\/strong>, qui arrache imm\u00e9diatement le CPU \u00e0 sa t\u00e2che actuelle et lance un gestionnaire. Les cartes r\u00e9seau signalent les nouveaux paquets, les contr\u00f4leurs de stockage signalent les E\/S termin\u00e9es, les temporisateurs d\u00e9clenchent les horloges - chacune de ces interruptions co\u00fbte cher. <strong>temps CPU<\/strong>. En cas d'activit\u00e9 \u00e9lev\u00e9e, ces \u00e9v\u00e9nements s'accumulent et entra\u00eenent de nombreux changements de contexte et des \u00e9checs de cache. C'est pourquoi j'observe \u00e0 quelle fr\u00e9quence et pendant combien de temps le CPU du noyau passe des ISR et des DPC. Comprendre cette dynamique permet de g\u00e9rer les temps de r\u00e9action de mani\u00e8re fiable et de maintenir des applications sensiblement plus fluides.<\/p>\n\n<h2>Pourquoi des temps d'interruption \u00e9lev\u00e9s co\u00fbtent-ils en performance ?<\/h2>\n\n<p>Dans les environnements sains, les interruptions du syst\u00e8me se situent g\u00e9n\u00e9ralement entre <strong>0,1-2%<\/strong> CPU, 3-7% sont possibles \u00e0 court terme. Si le temps d'interruption reste r\u00e9guli\u00e8rement sup\u00e9rieur \u00e0 5-10%, il s'agit souvent d'un probl\u00e8me de pilote, de mat\u00e9riel d\u00e9fectueux ou d'un mauvais r\u00e9glage. A partir de 30%, les choses deviennent s\u00e9rieuses, au-del\u00e0 de 50%, les risques suivants se pr\u00e9sentent <strong>Goulots d'\u00e9tranglement<\/strong> et des temps de r\u00e9ponse difficiles. Les applications perdent du d\u00e9bit, les latences sautent et la pr\u00e9visibilit\u00e9 en souffre. Je v\u00e9rifie alors d'abord les niveaux des pilotes, le firmware, les affinit\u00e9s et la mod\u00e9ration des interruptions sur les cartes r\u00e9seau.<\/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\/04\/server_interrupts_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interruptions simultan\u00e9es : comprendre les latences<\/h2>\n\n<p>Une seule interruption reste rarement un <strong>Probl\u00e8me<\/strong>; La situation devient difficile lorsque plusieurs \u00e9v\u00e9nements entrent en collision. Si une interruption de haute priorit\u00e9 arrive pendant une interruption de basse priorit\u00e9, le traitement de cette derni\u00e8re est prolong\u00e9 par de nouvelles interruptions. Exemple : si le chemin \u00e0 haute priorit\u00e9 n\u00e9cessite 75 cycles et le chemin \u00e0 faible priorit\u00e9 50, la latence du chemin \u00e0 faible priorit\u00e9 augmente facilement jusqu'\u00e0 125 cycles - d'autres chevauchements font augmenter la latence. <strong>Pire cas de figure<\/strong>-latence augmente rapidement. Ce comportement rend les syst\u00e8mes impr\u00e9visibles. C'est pourquoi je planifie les affinit\u00e9s principales et les priorit\u00e9s de mani\u00e8re \u00e0 ce que les hotpaths ne se bloquent pas mutuellement.<\/p>\n\n<h2>MSI et MSI-X au quotidien<\/h2>\n\n<p>Les h\u00f4tes modernes utilisent MSI ou <strong>MSI-X<\/strong>, Au lieu d'envoyer des signaux de ligne classiques (lignes IRQ). MSI transmet le message sous forme d'\u00e9criture en m\u00e9moire et r\u00e9duit ainsi la latence et la sensibilit\u00e9 aux perturbations. MSI-X \u00e9tend le concept : plus de messages, des files d'attente s\u00e9par\u00e9es, une r\u00e9partition plus cibl\u00e9e sur les noyaux. Cela permet de r\u00e9duire les collisions d'interruptions et d'am\u00e9liorer la s\u00e9curit\u00e9. <strong>Mise \u00e0 l'\u00e9chelle<\/strong> \u00e0 haut d\u00e9bit. J'active MSI-X pour les cartes r\u00e9seau et les contr\u00f4leurs NVMe, dans la mesure o\u00f9 les pilotes et le micrologiciel le supportent de mani\u00e8re stable.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>m\u00e9canisme<\/th>\n      <th>Max a \u00e9t\u00e9 cr\u00e9\u00e9. Messages<\/th>\n      <th>Adressage<\/th>\n      <th>R\u00e9partition sur les noyaux<\/th>\n      <th>Effet typique<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>IRQ patrimoniale<\/td>\n      <td>1 par appareil\/ligne<\/td>\n      <td>Signal de ligne<\/td>\n      <td>Limit\u00e9<\/td>\n      <td>Plus haut <strong>Latence<\/strong>, plus de collisions<\/td>\n    <\/tr>\n    <tr>\n      <td>MSI<\/td>\n      <td>Jusqu'\u00e0 ~32<\/td>\n      <td>\u00c9criture en m\u00e9moire (16 bits)<\/td>\n      <td>Bon<\/td>\n      <td>Moins d'overhead, des chemins plus stables<\/td>\n    <\/tr>\n    <tr>\n      <td>MSI-X<\/td>\n      <td>Jusqu'en 2048<\/td>\n      <td>\u00c9criture en m\u00e9moire (32 bits)<\/td>\n      <td>Tr\u00e8s bon<\/td>\n      <td>Plus fin <strong>Distribution<\/strong>, parall\u00e9lisme plus \u00e9lev\u00e9<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/server-cpu-interrupts-performance-4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>DMA, DPC et le bon chemin de donn\u00e9es<\/h2>\n\n<p>Le DMA permet aux appareils d'enregistrer des donn\u00e9es directement dans le <strong>M\u00e9moire<\/strong> le CPU ne d\u00e9clenche plus que des routines de traitement. Cela permet d'\u00e9conomiser des interruptions, car moins d'\u00e9tats interm\u00e9diaires doivent \u00eatre signal\u00e9s. Je veille \u00e0 ce que les DPC concentrent le travail r\u00e9el au lieu d'en faire trop dans l'ISR. Ainsi, le temps dans la section critique reste court et les <strong>Latence<\/strong> de mani\u00e8re plus pr\u00e9visible. Au total, l'unit\u00e9 centrale gagne plus de temps pour la logique de l'application.<\/p>\n\n<h2>Configurer de mani\u00e8re cibl\u00e9e le RSS et l'affinit\u00e9 CPU<\/h2>\n\n<p>Receive Side Scaling r\u00e9partit les queues de r\u00e9seau et leurs interruptions sur plusieurs <strong>noyaux<\/strong>. Je lie chaque file d'attente, y compris l'interruption, le DPC et le thread utilisateur, au m\u00eame noyau ou au m\u00eame cluster de noyaux afin d'\u00e9viter les r\u00e9veils crois\u00e9s. Si diff\u00e9rents noyaux interviennent dans un flux, les \u00e9checs de cache et les changements de contexte augmentent. Un plan d'affinit\u00e9 structur\u00e9 emp\u00eache sensiblement de telles pertes de friction. Pour ceux qui souhaitent approfondir le sujet, voici un guide compact <a href=\"https:\/\/webhosting.de\/fr\/serveur-cpu-affinity-hebergement-optimisation-kernelaffinity\/\">Affinit\u00e9 avec le CPU<\/a>-Aper\u00e7u des configurations d'h\u00e9bergement.<\/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\/04\/cpu_interrupts_nachtbild_4832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>D\u00e9samorcer les interruptions de stockage et les chemins d'E\/S<\/h2>\n\n<p>Le stockage g\u00e9n\u00e8re \u00e9galement beaucoup <strong>Interruptions<\/strong>, surtout avec beaucoup de petites IOPS. J'utilise MSI-X sur des contr\u00f4leurs NVMe et j'attribue des queues \u00e0 des noyaux fixes afin que les entr\u00e9es et les sorties restent locales. En outre, un <a href=\"https:\/\/webhosting.de\/fr\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/\">Planificateur d'E\/S<\/a>, La charge par file d'attente est liss\u00e9e. Les variantes Deadline, BFQ ou MQ r\u00e9agissent tr\u00e8s diff\u00e9remment en fonction de la charge de travail. En testant proprement, on r\u00e9duit la gigue et on augmente le temps de r\u00e9ponse. <strong>D\u00e9bit<\/strong>.<\/p>\n\n<h2>Temp\u00eates de r\u00e9seau, floods SYN et mod\u00e9ration des interruptions<\/h2>\n\n<p>Des flots soudains de paquets poussent <strong>ISR<\/strong>-et privent le CPU d'air. J'active la mod\u00e9ration des interruptions sur la carte r\u00e9seau de mani\u00e8re \u00e0 ce que les paquets arrivent en rafales raisonnables, sans g\u00e9n\u00e9rer de pics de latence. Dans les sc\u00e9narios de DoS, une connexion r\u00e9siliente stabilise le trafic. <a href=\"https:\/\/webhosting.de\/fr\/syn-protection-contre-les-inondations-socket-handling-server-defense\/\">D\u00e9fense SYN-Flood<\/a> le tableau de connexion de mani\u00e8re pr\u00e9coce. En m\u00eame temps, je mesure si la mod\u00e9ration elle-m\u00eame r\u00e9agit trop lentement - dans ce cas, j'ajuste les valeurs. L'objectif est d'obtenir un flux de paquets calme qui permette aux DPC de se d\u00e9placer de mani\u00e8re r\u00e9guli\u00e8re. <strong>nourrit<\/strong>.<\/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\/04\/cpu_interrupts_server_3416.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring : lire les chiffres et agir<\/h2>\n\n<p>Je commence par quelques points clairs <strong>M\u00e9triques<\/strong>: utilisation totale du CPU, temps d'interruption, temps DPC, changement de contexte et file d'attente du processeur. Si le CPU reste la plupart du temps en dessous de 50%, je r\u00e9agis calmement ; \u00e0 50-80%, j'observe les pics et les points chauds ; au-dessus de 80%, je planifie une mise \u00e0 l'\u00e9chelle ou un r\u00e9glage. Si le temps d'interruption d\u00e9passe 30%, je v\u00e9rifie les pilotes, le firmware et les affinit\u00e9s. Un contr\u00f4le de la latence pour l'audio\/vid\u00e9o montre indirectement \u00e0 quel point le noyau r\u00e9agit de mani\u00e8re d\u00e9terministe. Important : je ne modifie qu'une <strong>Variable<\/strong> par test et mesure \u00e0 nouveau ensuite.<\/p>\n\n<h2>Topologie NUMA et localit\u00e9 PCIe<\/h2>\n\n<p>Sur les h\u00f4tes multi-socket, je d\u00e9termine toujours les affinit\u00e9s d'interruption dans le contexte de la <strong>NUMA<\/strong>-topologie de la carte. Une carte r\u00e9seau ou un contr\u00f4leur NVMe est physiquement attach\u00e9 \u00e0 un complexe PCIe racine et donc \u00e0 un n\u0153ud NUMA. Je place les files d'attente et leurs interruptions sur <em>lointain<\/em> noyaux, les donn\u00e9es passent par des liens UPI\/QPI - les latences augmentent, la bande passante diminue. Je v\u00e9rifie donc \u00e0 quel n\u0153ud NUMA un p\u00e9riph\u00e9rique est associ\u00e9, je lie ses files d'attente aux noyaux locaux et je m'assure que les threads utilisateurs associ\u00e9s utilisent le m\u00eame n\u0153ud. Sous Windows, je tiens compte des groupes de processeurs et du param\u00e9trage du p\u00e9riph\u00e9rique pour le n\u0153ud NUMA pr\u00e9f\u00e9r\u00e9 ; sous Linux, je lie les IRQ, les softirqs et les threads d'application de mani\u00e8re coh\u00e9rente au n\u0153ud local. R\u00e9sultat : moins de trafic entre les n\u0153uds, une meilleure stabilit\u00e9. <strong>Jitter<\/strong>-et des temps de latence pr\u00e9visibles dans le pire des cas.<\/p>\n\n<h2>Utiliser correctement les offloads, NAPI et le coalescing<\/h2>\n\n<p>Les offloads sont de puissants leviers contre les inondations d'interruptions - mais ils doivent \u00eatre utilis\u00e9s pour le <strong>Charge de travail<\/strong> s'adapter \u00e0 la situation. En gros, cela se r\u00e9sume ainsi : Le TSO\/GSO d\u00e9place la segmentation vers la NIC, le LRO\/GRO regroupe les segments entrants, le RSC sur l'h\u00f4te agit de mani\u00e8re similaire au LRO. Pour les transferts en vrac (sauvegarde, r\u00e9plication), ces fonctionnalit\u00e9s augmentent le d\u00e9bit et r\u00e9duisent nettement le taux ISR. Pour les flux critiques en termes de latence (RPC, trading, VoIP), les grandes agr\u00e9gations peuvent toutefois <em>Temps de r\u00e9ponse<\/em> prolonger la dur\u00e9e de vie. J'opte donc pour des r\u00e9glages mod\u00e9r\u00e9s : GRO oui, mais sans exag\u00e9rer ; LRO seulement si aucun appareil mid-path ou pare-feu ne pose probl\u00e8me ; laisser TSO\/GSO actif en r\u00e8gle g\u00e9n\u00e9rale. <\/p>\n\n<p>NAPI sur Linux passe du mode interruption pure au mode poll \u00e0 partir de la charge. Cela permet de lisser les pics et de garder le CPU occup\u00e9 dans le chemin DPC au lieu de d\u00e9clencher des milliers de courtes ISR. Avec <strong>Mod\u00e9ration des interruptions<\/strong> (Coalescing), un plan se dessine : des minuteries courtes pour les profils interactifs, des minuteries plus longues pour le vrac. Je teste les intervalles par paliers de quelques microsecondes, j'observe les drops, les niveaux de remplissage des anneaux et les latences et trouve ainsi le \"sweet spot\". Dans la pile de stockage, des vis de r\u00e9glage analogues (Queue-Depth, NCQ, optimisations blk-mq) fournissent le m\u00eame effet : moins de staccato, plus de <strong>Efficacit\u00e9<\/strong>.<\/p>\n\n<h2>\u00c9quilibrage IRQ vs. \u00e9pinglage statique<\/h2>\n\n<p>L'\u00e9quilibrage automatique des IRQ r\u00e9partit la charge de mani\u00e8re acceptable - mais pas parfaite. Dans les environnements web homog\u00e8nes, je le laisse souvent fonctionner et ne contr\u00f4le que les hotspots. Dans les configurations \u00e0 latence critique ou asym\u00e9triques, il est <strong>\u00e9pinglage statique<\/strong> de la r\u00e9flexion : Je d\u00e9finis des ensembles fixes de processeurs par file d'attente et par p\u00e9riph\u00e9rique, je les maintiens coh\u00e9rents gr\u00e2ce aux red\u00e9marrages et je minimise les d\u00e9placements des softirqs. En outre, je r\u00e9serve des noyaux \u201ehousekeeping\u201c pour le travail en arri\u00e8re-plan (timer, Kthreads), afin que les noyaux de performance restent libres. Sous Windows, j'utilise de mani\u00e8re cibl\u00e9e le steering d'interruption et les masques d'affinit\u00e9 par file d'attente ; sous Linux, je travaille avec l'affinit\u00e9 per-IRQ et le contr\u00f4le Softirq. La devise : autant d'automatisme que n\u00e9cessaire, autant de <strong>D\u00e9terminisme<\/strong> que possible.<\/p>\n\n<h2>Virtualisation et SR-IOV\/virtio<\/h2>\n\n<p>Dans les VM, il y a des co\u00fbts suppl\u00e9mentaires : les interruptions virtuelles signifient <em>Exits VM<\/em>, les retards d'ordonnancement et les files d'attente partag\u00e9es. J'\u00e9pingle les vCPU \u00e0 forte intensit\u00e9 d'E\/S sur les pCPU correspondants, j'\u00e9vite l'overcommit sur les h\u00f4tes d'E\/S et je s\u00e9pare les threads de plan de donn\u00e9es de la charge de gestion. Dans la mesure du possible, j'utilise <strong>SR-IOV<\/strong>Les fonctions virtuelles apportent MSI-X jusque dans la VM de l'invit\u00e9 et soulagent le chemin de l'hyperviseur. Pour les charges de travail g\u00e9n\u00e9riques, virtio fournit des r\u00e9sultats solides avec l'acc\u00e9l\u00e9ration vhost ; dans les sc\u00e9narios \u00e0 haut d\u00e9bit, je mappe les files d'attente 1:1 sur les vCPU et je garde les affinit\u00e9s coh\u00e9rentes de l'invit\u00e9 \u00e0 l'h\u00f4te. Important : les m\u00eames r\u00e8gles concernant le RSS, le coalescing et le NUMA s'appliquent \u00e9galement aux VMs - seules les <strong>Transparence<\/strong> est plus faible, c'est pourquoi je mesure plus \u00e9troitement.<\/p>\n\n<h2>Gestion de l'\u00e9nergie et latences d\u00e9terministes<\/h2>\n\n<p>Les fonctions d'\u00e9conomie d'\u00e9nergie sont bonnes pour le bilan mais mauvaises pour les <strong>Budgets de latence<\/strong>. Les C-States profonds prolongent le temps de r\u00e9veil, les changements de fr\u00e9quence agressifs provoquent de la gigue. Sur les h\u00f4tes avec des SLO stricts, je d\u00e9finis des profils de performance, je limite les C-States profonds des paquets et je n'autorise le turbo que l\u00e0 o\u00f9 la r\u00e9serve thermique est suffisamment importante. Les d\u00e9cisions concernant les temporisateurs (temporisateurs \u00e0 haute r\u00e9solution vs. fr\u00e9quence d'interruption plus faible) influencent \u00e9galement la quantit\u00e9 et la cadence du travail du noyau. Dans les configurations proches du temps r\u00e9el, les modes sans horloge et les noyaux isol\u00e9s sont utiles : les threads d'application sur des noyaux isol\u00e9s, le travail syst\u00e8me sur des noyaux de \u201ehousekeeping\u201c d\u00e9di\u00e9s - de cette mani\u00e8re, le temps critique est conserv\u00e9. <strong>Hotpath<\/strong> exempts de tirs parasites.<\/p>\n\n<h2>Outils et m\u00e9thodologie de mesure par OS<\/h2>\n\n<p>Je tiens mes <strong>Cha\u00eene de diagnostic<\/strong> l\u00e9ger et reproductible. Sous Linux, je commence par \/proc\/interrupts et \/proc\/softirqs, je v\u00e9rifie les compteurs per-queue via ethtool et je regarde les param\u00e8tres de coalescence et de d\u00e9chargement. mpstat, vmstat et sar montrent les tendances des macros ; perf d\u00e9tecte les hotspots dans les ISR\/DPC. Je corr\u00e8le les compteurs de paquets et de drop avec les temps du noyau et les m\u00e9triques de flux. Sous Windows, les indicateurs de performance sur le temps d'interruption\/DPC, les interruptions\/sec et les DPC\/sec fournissent une image propre ; les traces montrent quels pilotes imposent la cadence. Ce qui est important, c'est le partage <strong>\u00c9chelle de temps<\/strong>Je synchronise tout pour que les pics, les drops et les sauts de latence correspondent.<\/p>\n\n<h2>Playbook de d\u00e9pannage et anti-patronage<\/h2>\n\n<p>Ma d\u00e9marche est coh\u00e9rente : d'abord <strong>Observer<\/strong>, puis une hypoth\u00e8se, puis un changement. Causes typiques : une file d'attente ou un p\u00e9riph\u00e9rique avec un taux ISR excessif, un firmware d\u00e9fectueux, des valeurs de coalescence trop \u00e9lev\u00e9es (syst\u00e8me tenace) ou trop basses (temp\u00eate ISR), des offloads qui regroupent trop de donn\u00e9es ou des threads qui tirent des files d'attente \u00e0 travers les n\u0153uds NUMA. J'isole le p\u00e9riph\u00e9rique concern\u00e9, je teste des param\u00e8tres par d\u00e9faut conservateurs, je modifie les pilotes\/BIOS et je r\u00e9partis proprement la charge. Anti-pattern : tout changer en m\u00eame temps, des rollbacks malpropres, pas de ligne de base ou des valeurs de mesure sans contexte. Celui qui pers\u00e9v\u00e8re dans une <strong>Variable<\/strong> une par une, on arrive rapidement \u00e0 une configuration stable.<\/p>\n\n<h2>Blueprints pour les h\u00f4tes 10\/25\/100G et NVMe<\/h2>\n\n<p>Pour les cartes r\u00e9seau 10G, je calcule 4 \u00e0 8 files d'attente RSS, en fonction de la g\u00e9n\u00e9ration de CPU et du profil des paquets. Je commence \u00e0 coalescer mod\u00e9r\u00e9ment (par ex. des microsecondes \u00e0 deux chiffres), GRO activ\u00e9, LRO prudent. \u00c0 25G, je passe \u00e0 8-16 files d'attente et je garde l'affinit\u00e9 strictement locale \u00e0 NUMA. A partir de 40\/100G, l'architecture de la file d'attente devient la <strong>Mission principale<\/strong>Beaucoup de files d'attente, une affectation propre par c\u0153ur, des charges utiles actives, la NAPI intervient sous charge. Pour le stockage NVMe, je mappe au moins une file d'attente par c\u0153ur et je garde la profondeur de la file d'attente adapt\u00e9e \u00e0 la charge de travail - les petites E\/S b\u00e9n\u00e9ficient de plus de parall\u00e9lisme, les gros transferts s\u00e9quentiels d'une politique de coalescence stable et d'un ordonnanceur qui lisse les bursts. L'objectif reste le m\u00eame : des latences constantes, pas de noyaux chauds, pas d'anneaux qui d\u00e9bordent.<\/p>\n\n<h2>Liste de contr\u00f4le pratique pour des r\u00e9sultats rapides<\/h2>\n\n<p>Je mets d'abord \u00e0 jour <strong>Pilote<\/strong> et le BIOS\/firmware, car les \u00e9tats d\u00e9fectueux font souvent grimper la charge d'interruption. Ensuite, je passe \u00e0 MSI-X si possible et r\u00e9partis proprement les files d'attente sur les noyaux. Je configure RSS de mani\u00e8re \u00e0 ce que les affinit\u00e9s de flux soient correctes et que les hotpaths restent coh\u00e9rents. Sur la carte r\u00e9seau, j'adapte la mod\u00e9ration au profil de trafic et j'observe l'effet sur les latences. Si je continue \u00e0 trouver des aberrations, je recherche le mat\u00e9riel d\u00e9fectueux, les mauvaises options ou les appareils probl\u00e9matiques par une proc\u00e9dure d'exclusion et une analyse s\u00e9par\u00e9e. <strong>Profilage<\/strong>.<\/p>\n\n<h2>\u00c9valuer le rapport co\u00fbt-b\u00e9n\u00e9fice de mani\u00e8re r\u00e9aliste<\/h2>\n\n<p>Tous les syst\u00e8mes n'ont pas besoin d'un maximum de <strong>Peaufinage<\/strong>. Je donne la priorit\u00e9 aux h\u00f4tes avec une charge de paquets \u00e9lev\u00e9e, beaucoup de petits IOPS ou une latence \u00e9troite. Quelques heures de r\u00e9glage y sont tr\u00e8s rentables, car moins de surcharge d'interruption lib\u00e8re imm\u00e9diatement le CPU pour l'application. Sur les serveurs non critiques, une configuration de base solide avec des pilotes actuels et MSI-X suffit. Ce sont les valeurs mesur\u00e9es qui me guident, pas l'intuition ou l'exp\u00e9rience. <strong>Pr\u00e9somptions<\/strong>.<\/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\/04\/interrupt-serverraum-1275.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>R\u00e9sum\u00e9 : Ce que je mets dans l'entretien quotidien<\/h2>\n\n<p>J'observe syst\u00e9matiquement <strong>Interruption<\/strong>- et DPC, je tiens les pilotes et le micrologiciel \u00e0 jour et j'utilise MSI-X lorsque c'est possible. Je planifie les RSS et les affinit\u00e9s par charge de travail afin que les flux, les DPC et les threads restent locaux. J'adapte la mod\u00e9ration de la carte r\u00e9seau aux mod\u00e8les de trafic, je r\u00e9partis proprement les files d'attente de stockage et j'utilise des chemins d'E\/S appropri\u00e9s. Si le monitoring montre des aberrations, je travaille en ligne droite \u00e0 travers les pilotes, le mat\u00e9riel et la configuration. Ainsi, le serveur de gestion des interruptions reste pr\u00e9visible et mes charges de travail fonctionnent de mani\u00e8re stable. <strong>Performance<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Apprendre comment la gestion des interruptions et les interruptions du processeur influencent les performances de l'h\u00e9bergement. Conseils pratiques pour optimiser les performances du serveur.<\/p>","protected":false},"author":1,"featured_media":18706,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-18713","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":"411","_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":"interrupt handling server","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":"18706","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18713","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=18713"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18713\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/18706"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=18713"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=18713"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=18713"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}