{"id":18945,"date":"2026-04-11T18:21:07","date_gmt":"2026-04-11T16:21:07","guid":{"rendered":"https:\/\/webhosting.de\/numa-balancing-server-memory-optimierung-hardware-numaflux\/"},"modified":"2026-04-11T18:21:07","modified_gmt":"2026-04-11T16:21:07","slug":"numa-balancing-serveur-optimisation-de-la-memoire-materiel-numaflux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/numa-balancing-server-memory-optimierung-hardware-numaflux\/","title":{"rendered":"Serveur d'\u00e9quilibrage NUMA : Optimisation de l'acc\u00e8s m\u00e9moire pour le mat\u00e9riel d'h\u00e9bergement"},"content":{"rendered":"<p>Je montre comment <strong>Serveur d'\u00e9quilibrage NUMA<\/strong> sur le mat\u00e9riel d'h\u00e9bergement, rationalise l'acc\u00e8s \u00e0 la m\u00e9moire et r\u00e9duit les latences en liant les processus et les donn\u00e9es au n\u0153ud NUMA appropri\u00e9. Le facteur d\u00e9cisif est la <strong>Optimisation de l'acc\u00e8s \u00e0 la m\u00e9moire<\/strong> gr\u00e2ce \u00e0 l'acc\u00e8s local, au placement de t\u00e2ches et \u00e0 la migration cibl\u00e9e de pages sur des h\u00f4tes Linux dot\u00e9s de nombreux c\u0153urs.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>NUMA<\/strong> s\u00e9pare les CPU et la m\u00e9moire en n\u0153uds ; les acc\u00e8s locaux fournissent <strong>faible<\/strong> Latence.<\/li>\n  <li><strong>Automatique<\/strong> NUMA Balancing migre les pages et place les t\u00e2ches <strong>pr\u00e8s du n\u0153ud<\/strong>.<\/li>\n  <li><strong>Taille de VM<\/strong> par n\u0153ud, sinon il y a risque de <strong>NUMA-Trashing<\/strong>.<\/li>\n  <li><strong>Outils<\/strong> comme le montrent numactl, lscpu, numad <strong>Topologie<\/strong> et l'utilisation.<\/li>\n  <li><strong>Tuning<\/strong>C-States, Node Interleaving off, <strong>Pages g\u00e9antes<\/strong>, Affinit\u00e9s.<\/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\/serverraum-speicheroptimum-5582.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ce qu'est NUMA - et pourquoi cela compte pour l'h\u00e9bergement<\/h2>\n\n<p>NUMA divise un syst\u00e8me multiprocesseur en <strong>N\u0153uds<\/strong>, qui contiennent chacun leur propre CPU et m\u00e9moire locale, ce qui rend les acc\u00e8s proches plus rapides que les acc\u00e8s distants. Alors qu'UMA envoie tous les c\u0153urs sur un chemin commun, NUMA \u00e9vite les goulets d'\u00e9tranglement gr\u00e2ce \u00e0 <strong>local<\/strong> canaux de m\u00e9moire par n\u0153ud. Dans les environnements d'h\u00e9bergement avec de nombreuses machines virtuelles parall\u00e8les, chaque milliseconde de latence s'additionne, c'est pourquoi chaque demande est mesurable. Pour ceux qui souhaitent approfondir le sujet, vous trouverez plus d'informations sur l'utilisation de l'espace de stockage en ligne. <a href=\"https:\/\/webhosting.de\/fr\/blog-numa-architecture-serveur-performance-hebergement-materiel-optimisation-infrastructure\/\">Architecture NUMA<\/a>. Pour moi, une chose est s\u00fbre : celui qui comprend et utilise les n\u0153uds tire davantage de bande passante du m\u00eame mat\u00e9riel.<\/p>\n\n<h2>L'\u00e9quilibrage automatique NUMA dans le noyau Linux - comment il fonctionne<\/h2>\n\n<p>Le noyau scanne p\u00e9riodiquement des parties de l'espace d'adressage et \u201ed\u00e9mappe\u201c des pages pour qu'un hinting fault ne bloque pas l'acc\u00e8s \u00e0 l'espace d'adressage. <strong>optimal<\/strong> n\u0153uds est visible. Si le d\u00e9faut se produit, l'algorithme \u00e9value s'il vaut la peine de migrer la page ou de d\u00e9placer la t\u00e2che et \u00e9vite les mouvements inutiles. Migrate-on-Fault apporte <strong>Donn\u00e9es<\/strong> plus pr\u00e8s de l'unit\u00e9 centrale ex\u00e9cutante, le placement de t\u00e2ches NUMA rapproche les processus de leur m\u00e9moire. Le scanner r\u00e9partit son travail au coup par coup afin que l'overhead reste dans le bruit de la charge normale. Il en r\u00e9sulte un r\u00e9glage fin permanent qui r\u00e9duit la latence sans exiger de r\u00e8gles d'\u00e9pinglage strictes.<\/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\/memoryoptimization1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimisation de l'acc\u00e8s \u00e0 la m\u00e9moire : le local bat le distant<\/h2>\n\n<p>Les acc\u00e8s locaux utilisent le <strong>Contr\u00f4leur de m\u00e9moire<\/strong> du propre n\u0153ud et minimisent les temps d'attente pour l'interconnexion. Les acc\u00e8s \u00e0 distance co\u00fbtent des cycles via QPI\/UPI ou Infinity Fabric et r\u00e9duisent ainsi le temps de connexion effectif. <strong>Bande passante<\/strong>. Un nombre \u00e9lev\u00e9 de c\u0153urs accentue cet effet, car de plus en plus de c\u0153urs sont en concurrence pour les m\u00eames connexions. Je planifie donc de mani\u00e8re \u00e0 ce que le code chaud et les donn\u00e9es actives se retrouvent sur un n\u0153ud. Si l'on ne respecte pas cette r\u00e8gle, on perd des points de pourcentage qui sont d\u00e9cisifs pour le temps de r\u00e9ponse ou le timeout lors des pics de charge.<\/p>\n\n<h2>Tailles de VM, NUMA-Trashing et d\u00e9coupage de l'h\u00f4te<\/h2>\n\n<p>Je dimensionne les VM de mani\u00e8re \u00e0 ce que les vCPU et la RAM tiennent dans un n\u0153ud NUMA, afin d'\u00e9viter les acc\u00e8s inter-n\u0153uds. Souvent, 4 \u00e0 8 vCPU par n\u0153ud fournissent de bonnes <strong>Taux de r\u00e9ussite<\/strong>, Cela d\u00e9pend de la plateforme et de la hi\u00e9rarchie du cache. De plus, les Huge Pages aident, car le TLB travaille plus efficacement et les migrations de pages sont moins fr\u00e9quentes. Si n\u00e9cessaire, je mets en place <strong>Affinit\u00e9 du CPU<\/strong> pour les processus critiques en termes de latence, afin de lier les threads aux noyaux appropri\u00e9s - pour plus d'informations, voir <a href=\"https:\/\/webhosting.de\/fr\/serveur-cpu-affinity-hebergement-optimisation-kernelaffinity\/\">Affinit\u00e9 du CPU<\/a>. Celui qui \u00e9tire des VM sur des n\u0153uds risque le NUMA trashing, c'est-\u00e0-dire un ping-pong de donn\u00e9es et de threads.<\/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\/numa-balancing-server-memory-2948.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Outils en pratique : numactl, lscpu, numad<\/h2>\n\n<p>Avec \u201elscpu\u201c, je lis <strong>Topologie<\/strong> et les n\u0153uds NUMA, y compris l'affectation des noyaux. \u201enumactl -hardware\u201c m'indique la m\u00e9moire par n\u0153ud et les distances disponibles, ce qui facilite l'\u00e9valuation des chemins. Le d\u00e9mon \u201enumad\u201c observe l'utilisation et adapte les affinit\u00e9s de mani\u00e8re dynamique lorsque les centres de charge se d\u00e9placent. Pour les sc\u00e9narios fixes, j'utilise \u201enumactl -cpunodebind\/-membind\u201c pour \u00e9pingler explicitement les processus et la m\u00e9moire. Je combine ainsi l'\u00e9quilibrage automatique avec des directives cibl\u00e9es et je contr\u00f4le le r\u00e9sultat via \u201eperf\u201c, \u201enumastat\u201c et \u201e\/proc\u201c.<\/p>\n\n<h2>Comment je mesure l'impact : Indicateurs et commandes<\/h2>\n\n<p>J'\u00e9value toujours NUMA-Tuning sur <strong>S\u00e9ries de mesures<\/strong>, et non par intuition. Trois indicateurs ont fait leurs preuves : Rapport entre le nombre de pages consult\u00e9es localement et le nombre de pages consult\u00e9es \u00e0 distance, taux de migration et r\u00e9partition de la latence (P95\/P99).<\/p>\n<ul>\n  <li><strong>\u00c0 l'\u00e9chelle du syst\u00e8me<\/strong>: \u201enumastat\u201c montre les acc\u00e8s locaux\/distants et les pages migr\u00e9es par n\u0153ud.<\/li>\n  <li><strong>En fonction du processus<\/strong>: \u201e\/proc\/\/numa_maps\u201c r\u00e9v\u00e8le o\u00f9 se trouve la m\u00e9moire et comment elle a \u00e9t\u00e9 r\u00e9partie.<\/li>\n  <li><strong>Vue de l'ordonnanceur<\/strong>: \u201eCpus_allowed_list\u201c et v\u00e9ritable \u201eCpus_allowed\u201c v\u00e9rifient si les liens sont effectifs.<\/li>\n<\/ul>\n<pre><code># Vue \u00e0 l'\u00e9chelle du syst\u00e8me\nnumastat\nnumastat -m\n\n# Distribution et binds li\u00e9s au processus\npid=$(pidof )\nnumastat -p \"$pid\"\ncat \/proc\/\"$pid\"\/numa_maps | head\ncat \/proc\/\"$pid\"\/status | grep -E 'Cpus_allowed_list|Mems_allowed_list\ntaskset -cp '$pid\"\n\n# Compteur du noyau pour l'activit\u00e9 NUMA\ngrep -E \"numa|migrate' \/proc\/vmstat\n\n# \u00c9v\u00e9nements de trace pour l'analyse en profondeur (activer bri\u00e8vement)\necho 1 &gt; \/sys\/kernel\/debug\/tracing\/events\/mm\/enable\nsleep 5 ; cat \/sys\/kernel\/debug\/tracing\/trace | grep -i numa ; echo 0 &gt; \/sys\/kernel\/debug\/tracing\/events\/mm\/enable\n<\/code><\/pre>\n<p>Je compare \u00e0 chaque fois <strong>A\/B<\/strong>: non li\u00e9 vs. li\u00e9, \u00e9quilibrage automatique on\/off et diff\u00e9rents d\u00e9coupages de VM. L'objectif est une nette diminution des acc\u00e8s distants et du bruit de migration ainsi que des latences P95\/P99 plus faibles. Ce n'est que lorsque les valeurs mesur\u00e9es sont stables et meilleures que je me charge du r\u00e9glage.<\/p>\n\n<h2>Param\u00e8tres du BIOS et du firmware qui portent vraiment<\/h2>\n\n<p>Je d\u00e9sactive \u201eNode Interleaving\u201c dans le BIOS pour que la structure NUMA reste visible et que le noyau <strong>local<\/strong> peut planifier. Des C-States r\u00e9duits stabilisent les pics de latence, car les noyaux tombent moins souvent en \u00e9tat de sommeil profond, ce qui permet d'\u00e9conomiser du temps de r\u00e9veil. J'attribue les canaux de m\u00e9moire de mani\u00e8re sym\u00e9trique afin que chaque n\u0153ud puisse utiliser sa capacit\u00e9 maximale. <strong>Bande passante<\/strong> est atteint. Je teste les fonctions Prefetcher et RAS avec des profils de charge de travail, car elles aident ou nuisent selon le mod\u00e8le d'acc\u00e8s. Je mesure chaque modification par rapport \u00e0 une ligne de base et ce n'est qu'ensuite que j'adopte le r\u00e9glage de mani\u00e8re permanente.<\/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\/NUMA_Balancing_Server_8345.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Param\u00e8tres du noyau et de Sysctl qui font la diff\u00e9rence<\/h2>\n\n<p>Le r\u00e9glage fin dans le noyau m'aide, <strong>Overhead<\/strong> et <strong>Temps de r\u00e9action<\/strong> de l'\u00e9quilibreur en fonction de la charge de travail. Je commence avec des valeurs par d\u00e9faut conservatrices et j'avance progressivement.<\/p>\n<ul>\n  <li><strong>kernel.numa_balancing<\/strong>On\/Off de l'\u00e9quilibrage automatique. Pour les charges itin\u00e9rantes, il reste activ\u00e9 chez moi ; pour les services sp\u00e9ciaux strictement \u00e9pingl\u00e9s, je le d\u00e9sactive \u00e0 titre d'essai.<\/li>\n  <li><strong>kernel.numa_balancing_scan_delay_ms<\/strong>: temps d'attente avant le premier balayage apr\u00e8s la cr\u00e9ation du processus. Choisir plus grand si beaucoup de t\u00e2ches \u00e0 courte dur\u00e9e de vie sont en cours d'ex\u00e9cution ; plus petit pour les services \u00e0 longue dur\u00e9e de vie qui ont besoin d'une proximit\u00e9 rapide.<\/li>\n  <li><strong>kernel.numa_balancing_scan_period_min_ms \/ _max_ms<\/strong>: largeur de bande des intervalles de balayage. Des intervalles serr\u00e9s augmentent la r\u00e9activit\u00e9, mais aussi la charge de l'unit\u00e9 centrale.<\/li>\n  <li><strong>kernel.numa_balancing_scan_size_mb<\/strong>: proportion de l'espace d'adressage par balayage. Trop grand, il g\u00e9n\u00e8re des temp\u00eates d'erreurs, trop petit, il r\u00e9agit paresseusement.<\/li>\n  <li><strong>vm.zone_reclaim_mode<\/strong>En cas de manque de m\u00e9moire, le noyau pr\u00e9f\u00e8re la r\u00e9cup\u00e9ration locale \u00e0 l'allocation \u00e0 distance. Pour les charges de travail d'h\u00e9bergement g\u00e9n\u00e9rales, je laisse g\u00e9n\u00e9ralement <em>0<\/em>; pour les services strictement sensibles \u00e0 la latence et localis\u00e9s en m\u00e9moire, je teste prudemment des valeurs plus \u00e9lev\u00e9es.<\/li>\n  <li><strong>Transparent Huge Pages (THP)<\/strong>: Sous \u201e\/sys\/kernel\/mm\/transparent_hugepage\/{enabled,defrag}\u201c, je r\u00e8gle g\u00e9n\u00e9ralement sur <em>madvise<\/em> et une d\u00e9fragmentation conservatrice. Les profils durs \u201ealways\u201c apportent certes des avantages en termes de TLB, mais risquent de provoquer des d\u00e9crochages en raison de la compaction.<\/li>\n  <li><strong>sched_migration_cost_ns<\/strong>: estimation des co\u00fbts pour la migration des t\u00e2ches. Des valeurs plus \u00e9lev\u00e9es att\u00e9nuent la redistribution des ordonnanceurs agressifs.<\/li>\n  <li><strong>cgroups cpuset<\/strong>: Avec <em>cpuset.cpus<\/em> et <em>cpuset.mems<\/em> je s\u00e9pare proprement les services par n\u0153ud et je m'assure que <strong>Premi\u00e8re touche<\/strong> reste dans les limites des n\u0153uds autoris\u00e9s.<\/li>\n<\/ul>\n<pre><code># Exemple : \u00e9quilibrage conservateur mais r\u00e9actif\nsysctl -w kernel.numa_balancing=1\nsysctl -w kernel.numa_balancing_scan_delay_ms=30000\nsysctl -w kernel.numa_balancing_scan_period_min_ms=60000\nsysctl -w kernel.numa_balancing_scan_period_max_ms=300000\nsysctl -w kernel.numa_balancing_scan_size_mb=256\n\n# Utiliser THP avec pr\u00e9caution\necho madvise &gt; \/sys\/kernel\/mm\/transparent_hugepage\/enabled\necho defer &gt; \/sys\/kernel\/mm\/transparent_hugepage\/defrag\n<\/code><\/pre>\n<p>Il reste important de le faire : Ne modifier qu'une seule vis de r\u00e9glage par cycle de test et tester l'effet contre la m\u00eame courbe de charge. C'est ainsi que je d\u00e9m\u00eale la cause et l'effet.<\/p>\n\n<h2>Placer correctement les charges de travail : Bases de donn\u00e9es, caches, conteneurs<\/h2>\n\n<p>Les bases de donn\u00e9es b\u00e9n\u00e9ficient du fait que les buffer pools par n\u0153ud NUMA restent locaux et que les threads sont li\u00e9s \u00e0 proximit\u00e9 de leurs tas. Dans les caches en m\u00e9moire, je r\u00e8gle le sharding sur <strong>N\u0153uds<\/strong> afin d'\u00e9viter les fetchs distants. Les plateformes de conteneurs re\u00e7oivent des limites et des requ\u00eates de mani\u00e8re \u00e0 ce que les pods ne sautent pas \u00e0 travers les n\u0153uds. Pour les r\u00e9servations de m\u00e9moire, j'utilise Huge Pages, ce qui permet de mieux placer les hotsets dans les <strong>Caches<\/strong> s'adapter \u00e0 la situation. Le tableau suivant r\u00e9sume de mani\u00e8re compacte les strat\u00e9gies et les effets typiques.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Strat\u00e9gie<\/th>\n      <th>Utilisation<\/th>\n      <th>Effet attendu<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Premi\u00e8re touche<\/td>\n      <td>Bases de donn\u00e9es, JVM-Heaps<\/td>\n      <td>Allocation lat\u00e9rale locale<\/td>\n      <td>Ex\u00e9cuter l'initialisation sur le n\u0153ud cible<\/td>\n    <\/tr>\n    <tr>\n      <td>Interleave<\/td>\n      <td>Charge largement r\u00e9partie<\/td>\n      <td>R\u00e9partition uniforme<\/td>\n      <td>Pas optimal pour les hotspots<\/td>\n    <\/tr>\n    <tr>\n      <td>\u00c9pinglage des t\u00e2ches<\/td>\n      <td>Services critiques en termes de latence<\/td>\n      <td>Latence constante<\/td>\n      <td>Moins de flexibilit\u00e9 lors des changements de charge<\/td>\n    <\/tr>\n    <tr>\n      <td>\u00c9quilibrage automatique<\/td>\n      <td>Charges de travail mixtes<\/td>\n      <td>Proximit\u00e9 dynamique<\/td>\n      <td>\u00c9valuer les frais g\u00e9n\u00e9raux par rapport aux b\u00e9n\u00e9fices<\/td>\n    <\/tr>\n    <tr>\n      <td>Pages g\u00e9antes<\/td>\n      <td>Grands tas, caches<\/td>\n      <td>Moins de m\u00e9saventures TLB<\/td>\n      <td>Pr\u00e9voir une r\u00e9servation propre<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Virtualisation : NUMA virtuel, planificateur et personnalisation des invit\u00e9s<\/h2>\n\n<p>Virtual NUMA transmet la topologie de l'h\u00f4te \u00e0 l'OS invit\u00e9 sous une forme simplifi\u00e9e, de sorte que First-Touch et <strong>Allocateur<\/strong> travailler de mani\u00e8re judicieuse. Les planificateurs d'hyperviseur font attention \u00e0 la proximit\u00e9 des n\u0153uds lorsqu'ils d\u00e9ploient des vCPU et migrent des VM. J'aligne rarement les grosses VM sur plusieurs n\u0153uds, sauf si la charge de travail diffuse largement et profite de l'entrelacement. Dans l'invit\u00e9, j'adapte les tas de JVM ou de bases de donn\u00e9es de mani\u00e8re \u00e0 ce qu'ils restent locaux sur des n\u0153uds NUMA visibles. Pour la gestion de la m\u00e9moire dans l'invit\u00e9, un coup d'\u0153il sur <a href=\"https:\/\/webhosting.de\/fr\/memoire-virtuelle-gestion-du-serveur-hebergement-memoire\/\">m\u00e9moire virtuelle<\/a>, pour dompter la taille des pages et le swapping.<\/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\/optimierung_hardware_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Proximit\u00e9 de la PCIe : NVMe et NIC aux bons n\u0153uds<\/h2>\n\n<p>Si possible, j'attribue les SSD NVMe et les cartes r\u00e9seau rapides au n\u0153ud sur lequel les <strong>Charge de travail<\/strong> est en cours d'ex\u00e9cution. J'\u00e9vite ainsi que les demandes d'E\/S ne traversent l'interconnexion et n'ajoutent de la latence. Je lie les NIC multi-queues aux ensembles de noyaux d'un n\u0153ud \u00e0 l'aide de RSS\/RPS, afin que les IRQ restent locales. Pour les piles de stockage, il est int\u00e9ressant de diviser les pools de threads par n\u0153ud. En faisant attention \u00e0 cela, on r\u00e9duit sensiblement les temps de latence P99 et on cr\u00e9e une marge de man\u0153uvre pour les pics de charge.<\/p>\n\n<h2>L'affinit\u00e9 IRQ et Queue dans la pratique<\/h2>\n\n<p>Je v\u00e9rifie d'abord sur quel <strong>N\u0153ud NUMA<\/strong> et \u00e9pingler les IRQ et les queues de mani\u00e8re appropri\u00e9e. De cette mani\u00e8re, la localit\u00e9 du chemin de donn\u00e9es est pr\u00e9serv\u00e9e.<\/p>\n<pre><code># Affectation d'un appareil \u00e0 un n\u0153ud\ncat \/sys\/class\/net\/eth0\/device\/numa_node\ncat \/sys\/block\/nvme0n1\/device\/numa_node\n\n# D\u00e9finir l'affinit\u00e9 IRQ de mani\u00e8re cibl\u00e9e (exemple : noyaux 0-7 d'un n\u0153ud)\nirq=\necho 0-7 &gt; \/proc\/irq\/$irq\/smp_affinity_list\n\n# Lier les queues de NIC aux noyaux (RPS\/RFS)\nfor q in \/sys\/class\/net\/eth0\/queues\/rx-* ; do echo 0-7 &gt; \"$q\"\/rps_cpus ; done\nsysctl -w net.core.rps_sock_flow_entries=32768\nfor q in \/sys\/class\/net\/eth0\/queues\/rx-* ; do echo 4096 &gt; \"$q\"\/rps_flow_cnt ; done\n\n# Am\u00e9liorer l'affinit\u00e9 de la file d'attente NVMe\necho 2 &gt; \/sys\/block\/nvme0n1\/queue\/rq_affinity\ncat \/sys\/block\/nvme0n1\/queue\/scheduler # \"none\" pr\u00e9f\u00e9r\u00e9\n<\/code><\/pre>\n<p>\u201eirqbalance\u201c, je l'ex\u00e9cute avec la conscience du noeud ou je mets <strong>exceptions<\/strong> pour les interruptions hot-path. Il en r\u00e9sulte des latences plus stables, moins de sauts d'IRQ entre les n\u0153uds et une augmentation mesurable des occurrences d'E\/S locales.<\/p>\n\n<h2>Liaison statique vs. \u00e9quilibrage dynamique - la voie m\u00e9diane<\/h2>\n\n<p>Avec \u201etaskset\u201c et cgroups, je fixe des r\u00e8gles strictes lorsque des <strong>Latence<\/strong> compte. Je laisse l'Automatic NUMA Balancing actif lorsque la charge se d\u00e9place et que j'ai besoin d'une proximit\u00e9 adaptative. Un m\u00e9lange fonctionne souvent mieux : des pins durs pour les hotpaths, des limites plus ouvertes pour le travail secondaire. Je v\u00e9rifie r\u00e9guli\u00e8rement si les migrations augmentent de mani\u00e8re significative, car cela signale une mauvaise planification. L'objectif reste de choisir des emplacements de donn\u00e9es et de threads de telle sorte que les migrations restent rares, mais possibles.<\/p>\n\n<h2>NUMA dans les conteneurs et Kubernetes<\/h2>\n\n<p>J'apporte le conteneur <strong>cpusets<\/strong> et <strong>Pages g\u00e9antes<\/strong> sur la ligne. J'attribue des pods\/conteneurs \u00e0 un n\u0153ud NUMA en d\u00e9posant des quantit\u00e9s coh\u00e9rentes de CPU et de m\u00e9moire. Dans les orchestrations, je place des politiques qui privil\u00e9gient les affectations \u00e0 un seul n\u0153ud et respectent ainsi le premier contact.<\/p>\n<ul>\n  <li><strong>Runtime du conteneur<\/strong>: \u201e-cpuset-cpus\u201c et \u201e-cpuset-mems\u201c maintiennent les t\u00e2ches et la m\u00e9moire ensemble ; allouer les Huge Pages comme ressources.<\/li>\n  <li><strong>Gestionnaire de topologie\/de CPU<\/strong>Allocations : Les allocations strictes ou pr\u00e9f\u00e9rentielles garantissent l'attribution de noyaux et de zones de m\u00e9moire associ\u00e9s.<\/li>\n  <li><strong>QoS garantie<\/strong>Requ\u00eates\/limites fixes minimisent les redistributions par l'ordonnanceur.<\/li>\n<\/ul>\n<p>Je divise d\u00e9lib\u00e9r\u00e9ment les sidecars et les processus auxiliaires sur d'autres noyaux <em>au sein de<\/em> du m\u00eame n\u0153ud, afin que le hotpath ne soit pas perturb\u00e9, mais ne se retrouve pas dans la course aux n\u0153uds crois\u00e9s.<\/p>\n\n<h2>Comprendre les topologies de CPU : CCD\/CCX, SNC et Cluster-on-Die<\/h2>\n\n<p>Les processeurs pour serveurs actuels d\u00e9composent les sockets en <strong>Sous-domaines<\/strong> avec leurs propres caches et chemins. J'en tiens compte lorsque je d\u00e9coupe des noyaux\/seaps :<\/p>\n<ul>\n  <li><strong>AMD EPYC<\/strong>CCD\/CCX et \u201eNUMA per Socket\u201c (NPS=1\/2\/4) influencent la finesse du d\u00e9coupage NUMA. Plus de n\u0153uds (NPS=4) augmentent la localit\u00e9, mais exigent un \u00e9pinglage propre.<\/li>\n  <li><strong>Intel<\/strong>Sub-NUMA Clustering (SNC2\/4) divise le LLC en clusters. Bon pour les charges li\u00e9es \u00e0 la m\u00e9moire, \u00e0 condition que l'OS et la charge de travail soient conscients des n\u0153uds.<\/li>\n  <li><strong>Proximit\u00e9 de L3<\/strong>Je lie les threads qui utilisent les m\u00eames tas dans la m\u00eame interconnexion L3 afin d'\u00e9conomiser le trafic de coh\u00e9rence et les sauts de clusters crois\u00e9s.<\/li>\n<\/ul>\n<p>Ces options agissent comme un multiplicateur : bien utilis\u00e9es, elles soul\u00e8vent <strong>Localit\u00e9<\/strong> en plus - mal configur\u00e9s, ils augmentent la fragmentation et le trafic \u00e0 distance.<\/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\/hosting-serverraum-7584.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Introduction progressive et plan de retour en arri\u00e8re<\/h2>\n\n<p>Je n'introduis jamais le NUMA-Tuning \u201eBig Bang\u201c. Un r\u00e9silient <strong>Plan<\/strong> \u00e9vite les surprises :<\/p>\n<ol>\n  <li><strong>Ligne de base<\/strong>: topologie mat\u00e9rielle, latences P50\/P95\/P99, throughput, capture du quota numastat.<\/li>\n  <li><strong>Hypoth\u00e8se<\/strong>: Formuler un objectif concret (par exemple, acc\u00e8s \u00e0 distance -30%, P99 -20%).<\/li>\n  <li><strong>Une \u00e9tape<\/strong>: ne modifier qu'une seule vis de r\u00e9glage (par ex. d\u00e9coupe VM, cpuset, politique THP, intervalles de balayage).<\/li>\n  <li><strong>Canary<\/strong>Tester sur 5-10% de la flotte sous charge r\u00e9elle, avoir le rollback pr\u00eat.<\/li>\n  <li><strong>\u00c9valuation<\/strong>: comparer les valeurs mesur\u00e9es, d\u00e9finir des fen\u00eatres de r\u00e9gression, consigner les effets secondaires.<\/li>\n  <li><strong>D\u00e9ploiement<\/strong>D\u00e9roulement : arbre par arbre, mesurer \u00e0 nouveau apr\u00e8s chaque arbre.<\/li>\n  <li><strong>Entretien<\/strong>: Remesurer tous les trimestres (les mises \u00e0 jour du noyau, du firmware, de la charge de travail modifient l'optimum).<\/li>\n<\/ol>\n<p>Je m'assure ainsi que les am\u00e9liorations sont reproductibles et qu'elles peuvent \u00eatre annul\u00e9es en quelques minutes en cas d'erreur.<\/p>\n\n<h2>Erreurs fr\u00e9quentes - et comment les \u00e9viter<\/h2>\n\n<p>Un faux pas typique est l'activation de l'entrelacement des n\u0153uds dans le BIOS, ce qui cache la topologie NUMA et <strong>\u00c9quilibrage<\/strong> de la machine. Tout aussi d\u00e9favorables : les VM avec plus de vCPU qu'un n\u0153ud n'en offre, ainsi que les Huge Pages r\u00e9serv\u00e9es de mani\u00e8re peu soign\u00e9e. Certains administrateurs \u00e9pinglent tout en dur et se privent ainsi de toute flexibilit\u00e9 lorsque les charges de travail se d\u00e9placent. D'autres s'en remettent enti\u00e8rement au noyau, bien que les zones sensibles dures exigent des r\u00e8gles claires. J'enregistre les s\u00e9ries de mesures, j'identifie rapidement les valeurs aberrantes et j'adapte progressivement la configuration et les politiques.<\/p>\n<ul>\n  <li><strong>THP \u201etoujours\u201c<\/strong> sans contr\u00f4le : une compression non planifi\u00e9e perturbe la latence. Je pr\u00e9f\u00e8re utiliser \u201emadvise\u201c et r\u00e9server les Huge Pages de mani\u00e8re cibl\u00e9e.<\/li>\n  <li><strong>vm.zone_reclaim_mode<\/strong> trop agressif : la r\u00e9cup\u00e9ration locale peut faire plus de mal que de bien au mauvais moment. Mesurer d'abord, aff\u00fbter ensuite.<\/li>\n  <li><strong>irqbalance aveugle<\/strong>Les IRQ non critiques se d\u00e9placent \u00e0 travers les n\u0153uds. Pour les hotpaths, je mets des exceptions ou des masques fixes.<\/li>\n  <li><strong>M\u00e9lange interleave + \u00e9pinglage dur<\/strong>Des politiques oppos\u00e9es g\u00e9n\u00e8rent un ping-pong. J'opte pour une ligne claire par service.<\/li>\n  <li><strong>Des cpusets pas tr\u00e8s propres<\/strong>Les conteneurs voient certes un n\u0153ud, mais mappent la m\u00e9moire dans d'autres n\u0153uds. Toujours d\u00e9finir \u201ecpuset.mems\u201c de mani\u00e8re coh\u00e9rente par rapport \u00e0 l'ensemble de l'unit\u00e9 centrale.<\/li>\n  <li><strong>Fonctionnalit\u00e9s Sub-NUMA<\/strong> activ\u00e9s, mais non utilis\u00e9s : Plus de n\u0153uds sans planification augmentent la fragmentation. N'activer qu'apr\u00e8s des tests.<\/li>\n<\/ul>\n\n<h2>En bref<\/h2>\n\n<p>NUMA Balancing Server rapproche de mani\u00e8re cibl\u00e9e les processus et les donn\u00e9es, ce qui permet d'augmenter la fr\u00e9quence et la qualit\u00e9 des acc\u00e8s locaux. <strong>Latence<\/strong> \u00eatre plus courte. Avec une taille de VM adapt\u00e9e, une configuration propre du BIOS et des outils comme numactl, on obtient une topologie claire que le noyau exploite. Virtual NUMA, Huge Pages et affinit\u00e9s compl\u00e8tent l'\u00e9quilibrage automatique au lieu de le remplacer. En connectant les appareils I\/O \u00e0 proximit\u00e9 des n\u0153uds et en pla\u00e7ant des hotpaths, on \u00e9limine les acc\u00e8s \u00e0 distance co\u00fbteux. Ainsi, le mat\u00e9riel d'h\u00e9bergement s'adapte de mani\u00e8re fiable et chaque seconde de CPU fournit plus d'\u00e9nergie. <strong>charge utile<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>**NUMA balancing server** r\u00e9volutionne l'optimisation de l'acc\u00e8s \u00e0 la m\u00e9moire sur **hardware d'h\u00e9bergement**. R\u00e9duisez la latence et maximisez les performances du serveur.<\/p>","protected":false},"author":1,"featured_media":18938,"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-18945","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":"544","_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":"NUMA Balancing 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":"18938","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18945","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=18945"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18945\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/18938"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=18945"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=18945"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=18945"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}