{"id":19865,"date":"2026-06-10T11:53:56","date_gmt":"2026-06-10T09:53:56","guid":{"rendered":"https:\/\/webhosting.de\/server-numa-locality-cpu-memory-affinity-optimierung-core\/"},"modified":"2026-06-10T11:53:56","modified_gmt":"2026-06-10T09:53:56","slug":"serveur-numa-localite-cpu-memoire-affinity-optimisation-core","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/server-numa-locality-cpu-memory-affinity-optimierung-core\/","title":{"rendered":"Server NUMA Locality et CPU Memory Affinity pour une performance d'h\u00e9bergement maximale"},"content":{"rendered":"<p><strong>Serveur NUMA<\/strong> La localisation et l'affinit\u00e9 de la m\u00e9moire CPU d\u00e9terminent \u00e0 quel point les threads travaillent pr\u00e8s de leur RAM et \u00e0 quel point les latences restent constantes dans les piles d'h\u00e9bergement. Je montre de mani\u00e8re pratique comment tu peux obtenir un meilleur d\u00e9bit mesurable avec la reconnaissance de la topologie, les strat\u00e9gies d'affinit\u00e9 et les chemins d'E\/S proches des n\u0153uds et <strong>Latence<\/strong> de mani\u00e8re significative.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<p>Pour une orientation rapide, je r\u00e9sume les messages cl\u00e9s avant d'expliquer les \u00e9tapes en d\u00e9tail et de les \u00e9tayer par des exemples ; tu peux ainsi voir directement par o\u00f9 tu dois commencer pour <strong>Localit\u00e9<\/strong> et d'utiliser Affinity de mani\u00e8re profitable. J'insiste sur les liens clairs entre les threads, la m\u00e9moire et les entr\u00e9es\/sorties, afin que tu puisses d\u00e9terminer les priorit\u00e9s de mani\u00e8re propre et <strong>D\u00e9cisions<\/strong> de la m\u00eame mani\u00e8re. Je citerai \u00e9galement des sc\u00e9narios dans lesquels l'entrelacement a du sens sans diluer tes chemins critiques, et je montrerai comment tu peux d\u00e9montrer de r\u00e9els progr\u00e8s par le biais du monitoring, et <strong>Erreur<\/strong> \u00e9viter les probl\u00e8mes. Pour les environnements virtualis\u00e9s, je donne des conseils sur le placement des vCPUs et de la vRAM, afin que les syst\u00e8mes invit\u00e9s ne glissent pas \u00e0 travers plusieurs n\u0153uds et que les syst\u00e8mes de stockage ne soient pas endommag\u00e9s. <strong>\u00c0 distance<\/strong>-Le nombre de visites explose. Pour finir, je transpose les connaissances acquises dans une courte feuille de route, afin que tu puisses proc\u00e9der de mani\u00e8re structur\u00e9e et que chaque \u00e9tape soit bien comprise. <strong>mesurable<\/strong> de la s\u00e9curit\u00e9.<\/p>\n<ul>\n  <li><strong>Localit\u00e9<\/strong> tout d'abord : garder les threads pr\u00e8s de sa propre RAM, \u00e9viter les threads distants.<\/li>\n  <li><strong>Affinity<\/strong> fixer les donn\u00e9es : Lier les noyaux et la m\u00e9moire par une politique.<\/li>\n  <li><strong>Topologie<\/strong> lire les informations : conna\u00eetre les n\u0153uds, les noyaux, les p\u00e9riph\u00e9riques PCIe par socket.<\/li>\n  <li><strong>Voies d'E\/S<\/strong> regrouper les donn\u00e9es : Coupler NIC, NVMe et App dans le m\u00eame n\u0153ud.<\/li>\n  <li><strong>salons<\/strong> au lieu de deviner : P95\/ P99, suivi des acc\u00e8s \u00e0 distance et du d\u00e9bit.<\/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-performance-1573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprendre la topologie de la NUMA<\/h2>\n\n<p>Avant de d\u00e9placer des charges de travail, je lis les <strong>Topologie<\/strong> du serveur : combien de n\u0153uds NUMA existent, combien de c\u0153urs et combien de RAM d\u00e9pendent de chaque n\u0153ud. Je regarde \u00e9galement quels p\u00e9riph\u00e9riques PCIe - tels que les cartes r\u00e9seau ou les disques SSD NVMe - sont connect\u00e9s \u00e0 quel socket, car cela d\u00e9termine les chemins d'interruption et l'acc\u00e8s \u00e0 la m\u00e9moire, ainsi que l'utilisation des ressources. <strong>Latence<\/strong> de l'utilisateur. Un n\u0153ud fournit un acc\u00e8s local \u00e0 la m\u00e9moire \u00e0 courte distance ; tout ce qui d\u00e9passe cette distance co\u00fbte du temps et de la bande passante. Plus la machine \u00e9volue avec plusieurs sockets, plus l'acc\u00e8s \u00e0 distance a un impact sur les temps de r\u00e9ponse et consomme de l'\u00e9nergie. <strong>D\u00e9bit<\/strong>. Pour une entr\u00e9e en mati\u00e8re compr\u00e9hensible dans la logique du mat\u00e9riel, je m'aide d'un manuel compact <a href=\"https:\/\/webhosting.de\/fr\/numa-nodes-server-hosting-grands-systemes-serverboost\/\">Vue d'ensemble des n\u0153uds NUMA<\/a>, Le syst\u00e8me de gestion de l'information de l'entreprise permet de prendre en compte les limites des n\u0153uds et d'\u00e9viter les erreurs de r\u00e9partition.<\/p>\n\n<p>Dans la pratique, je commence par un bref inventaire de la topologie et je le documente afin de pouvoir en d\u00e9duire plus tard des d\u00e9cisions d'affinit\u00e9 compr\u00e9hensibles. Commandes utiles :<\/p>\n<pre><code># noyaux et affectation NUMA\nlscpu -e=CPU,Core,Socket,Node\n\n# Aper\u00e7u du mat\u00e9riel NUMA\nnumactl --hardware\n\n# Associer les p\u00e9riph\u00e9riques PCIe \u00e0 leur n\u0153ud NUMA\nlspci -nn | grep -E \"Ethernet|Non-Volatile\"\nfor d in \/sys\/bus\/pci\/devices\/* ; do echo -n \"$d : \" ; cat $d\/numa_node ; done\n<\/code><\/pre>\n<p>Ce qui est important, c'est que tu <strong>PCIe-Root-Complex<\/strong> et les slots de p\u00e9riph\u00e9riques aux sockets. Deux ports de la m\u00eame carte r\u00e9seau peuvent \u00eatre attribu\u00e9s \u00e0 des n\u0153uds diff\u00e9rents ; cela influence l'endroit o\u00f9 les queues RX\/TX et les IRQ sont les mieux plac\u00e9s. Il en va de m\u00eame pour NVMe : les contr\u00f4leurs modernes poss\u00e8dent plusieurs files d'attente que tu devrais lier aux noyaux \u00e0 proximit\u00e9 des n\u0153uds afin d'\u00e9viter que le DMA ne d\u00e9clenche des sauts de n\u0153uds.<\/p>\n\n<h2>Utiliser correctement la m\u00e9moire CPU Affinity<\/h2>\n\n<p>Avec l'affinit\u00e9 m\u00e9moire CPU, j'associe fermement les processus aux zones centrales et je force l'allocation de m\u00e9moire la plus locale possible, afin que <strong>Fils de discussion<\/strong> ne pas constamment passer par le bord du n\u0153ud. Sous Linux, je d\u00e9finis les CPUs via systemd ou cgroups et je les combine avec des politiques de m\u00e9moire, de sorte que la RAM soit cr\u00e9\u00e9e de pr\u00e9f\u00e9rence sur le m\u00eame n\u0153ud, et <strong>\u00c0 distance<\/strong> reste minimis\u00e9e. Les services critiques - frontaux API, caches en m\u00e9moire, bases de donn\u00e9es - en profitent imm\u00e9diatement, car les temps d'attente sur les contr\u00f4leurs de m\u00e9moire deviennent plus rares et les occurrences de cache plus fr\u00e9quentes. Des limites d'\u00e9pinglage trop strictes peuvent toutefois limiter l'ordonnancement, c'est pourquoi je s\u00e9curise chaque adaptation avec des benchmarks et observe les valeurs P95\/ P99 pour des effets perceptibles sur <strong>Utilisateur<\/strong>-exp\u00e9rience de travail. Une introduction compacte \u00e0 Affinity dans l'h\u00e9bergement aide \u00e0 d\u00e9marrer : <a href=\"https:\/\/webhosting.de\/fr\/processus-serveur-affinity-numa-awareness-hosting-ressourcentuning\/\">Affinit\u00e9 et sensibilisation \u00e0 la NUMA<\/a> fournissent les outils n\u00e9cessaires pour un placement propre.<\/p>\n\n<p>Ce qui est d\u00e9cisif, c'est le <strong>Principe de la premi\u00e8re touche<\/strong>La m\u00e9moire est cr\u00e9\u00e9e sur le n\u0153ud qui \u00e9crit en premier dans la page. Initialise donc de grands tas ou tampons sur les noyaux cibles du n\u0153ud dans lequel le service sera ex\u00e9cut\u00e9 plus tard - id\u00e9alement avec une politique CPU et m\u00e9moire d\u00e9j\u00e0 d\u00e9finie (par ex. via systemd-Unit ou numactl). Si tu d\u00e9marres \u00e0 froid sur le n\u0153ud 0, puis que tu d\u00e9places les threads sur le n\u0153ud 1, une grande partie des pages reste \u00e0 distance. Pour les tas de gros runtimes, il vaut la peine de \u201epr\u00e9-toucher\u201c pendant le bootstrap, afin que les pages pourrissent localement et restent ensuite chaudes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/server_numa_affinity_2763.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sensibilisation \u00e0 la NUMA dans la pile d'h\u00e9bergement<\/h2>\n\n<p>Un syst\u00e8me d'exploitation conscient de la NUMA, un hyperviseur adapt\u00e9 et des applications avec thread-inning d\u00e9ploient ensemble leur plein potentiel. <strong>Potentiel<\/strong>. Le syst\u00e8me d'exploitation privil\u00e9gie le placement local lorsque des ressources libres sont disponibles dans le n\u0153ud, tandis que l'hyperviseur alloue les VM de mani\u00e8re \u00e0 ce que les vCPU et les vRAM ne d\u00e9rivent pas, et <strong>Localit\u00e9<\/strong> est pr\u00e9serv\u00e9e. Dans l'application, je s\u00e9pare les pools de travail par n\u0153ud et je garde les files d'attente locales au lieu d'exploiter des pools globaux de mani\u00e8re transversale. J'organise les processus de base de donn\u00e9es, les d\u00e9mons de cache et les instances de serveur web n\u0153ud par n\u0153ud, afin que les hotpaths restent courts et que l'acc\u00e8s aux donn\u00e9es ne soit pas limit\u00e9. <strong>Jitter<\/strong> diminue. La coh\u00e9rence et la pr\u00e9visibilit\u00e9 sous charge augmentent ainsi, ce qui influence directement la planifiabilit\u00e9 des SLA en euros et permet d'\u00e9conomiser un surprovisionnement co\u00fbteux.<\/p>\n\n<p>Au niveau d'Ingress, je veille \u00e0 ce que <strong>Affinit\u00e9 avec les nodes<\/strong> des sessions, par exemple par un routage collant ou un hachage coh\u00e9rent (par exemple sur l'IP du client ou le jeton de session), afin que les demandes reviennent \u00e0 \u201eleur\u201c travailleur local et \u00e0 la m\u00e9moire cache du n\u0153ud. Pour les services stateful, je planifie des r\u00e9pliques par n\u0153ud et j'\u00e9quilibre les acc\u00e8s en lecture au niveau local ; j'\u00e9galise les chemins d'\u00e9criture via la r\u00e9plication asynchrone ou le batching afin d'\u00e9viter le ping-pong inter-n\u0153uds.<\/p>\n\n<h2>Planifier les services n\u0153ud par n\u0153ud<\/h2>\n\n<p>Je regroupe les couches d'une pile de mani\u00e8re \u00e0 ce que chaque niveau ait une r\u00e9f\u00e9rence claire au node, et <strong>Chemins<\/strong> rester court. Une s\u00e9paration classique : Web\/ API par n\u0153ud, App-Worker \u00e0 c\u00f4t\u00e9, plus le cache local ; la base de donn\u00e9es se trouve \u00e9galement \u00e0 proximit\u00e9 du n\u0153ud, si l'empreinte de la RAM y est compatible et <strong>IO<\/strong>-ne soit pas interrompu. Je d\u00e9place les t\u00e2ches de reporting, les sauvegardes ou les traitements par lots vers des n\u0153uds moins critiques afin que les demandes interactives ne soient pas affect\u00e9es. J'\u00e9vite les grandes instances monolithiques, car elles d\u00e9passent souvent les limites des n\u0153uds et g\u00e9n\u00e8rent ainsi une charge distante qui est <strong>Performance<\/strong> estomp\u00e9. Des instances plus petites et r\u00e9pliqu\u00e9es par n\u0153ud fournissent souvent un meilleur d\u00e9bit au quotidien, car elles respectent les r\u00e8gles du NUMA et lissent les pics.<\/p>\n\n<p>Pour la planification des capacit\u00e9s, je compte <strong>marge<\/strong> s\u00e9par\u00e9ment par n\u0153ud : tampon CPU pour les rafales, tampon RAM contre OOM et marges propres pour le cache de page. J'\u00e9vite ainsi que le noyau ne se d\u00e9place involontairement \u00e0 distance. Pour le basculement, je d\u00e9finis des chemins de commutation clairs : si un n\u0153ud tombe en panne, les instances de remplacement peuvent certes s'ex\u00e9cuter de mani\u00e8re crois\u00e9e, mais je limite leur concourance jusqu'\u00e0 ce que le n\u0153ud d'origine soit restaur\u00e9 - la latence globale reste ainsi stable.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/server-performance-numa-locality-4759.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>D\u00e9finir l'affinit\u00e9 CPU : M\u00e9thodes et pi\u00e8ges<\/h2>\n\n<p>Pour l'attribution des noyaux, j'utilise systemd avec CPUAffinity ou cgroups avec cpuset.cpus, afin que les services aient des valeurs fixes. <strong>Domaines cl\u00e9s<\/strong> sont pr\u00e9serv\u00e9s. Lors de l'\u00e9pinglage, je fais attention aux paires hyper-threading, car deux threads logiques d'une unit\u00e9 physique partagent des ressources et peuvent se ralentir mutuellement si je les combine malencontreusement et <strong>Pointes<\/strong> g\u00e9n\u00e8rent. Les chemins de latence - la terminaison TLS, le recours \u00e0 l'API, les lecteurs de cache - re\u00e7oivent des noyaux exclusifs, tandis que les logs, la compression ou les sauvegardes se d\u00e9placent vers d'autres pools. Des pools trop \u00e9troits sans tampon provoquent des files d'attente, c'est pourquoi je tiens compte de la marge de man\u0153uvre et je v\u00e9rifie les changements de contexte, la longueur de la file d'attente et la qualit\u00e9 de la m\u00e9moire. <strong>IRQ<\/strong>-r\u00e9partition de la latence. Je d\u00e9duis de l'observation si j'ouvre plus largement les noyaux ou si je les concentre davantage jusqu'\u00e0 ce que la r\u00e9partition de la latence chute proprement et que les pics du P99 deviennent plus silencieux.<\/p>\n\n<p>Pour r\u00e9duire encore plus la gigue, j'utilise s\u00e9lectivement des commutateurs du noyau comme <strong>nohz_full<\/strong> et <strong>rcu_nocbs<\/strong> pour des noyaux de latence exclusifs, les isoler des services syst\u00e8me et ne placer d\u00e9lib\u00e9r\u00e9ment des IRQ que sur des CPU pr\u00e9vus \u00e0 cet effet. J'utilise le service \u201eirqbalance\u201c avec pr\u00e9caution : soit je le configure de mani\u00e8re cibl\u00e9e, soit je le d\u00e9sactive s'il contrecarre ton affinit\u00e9 manuelle avec les IRQ. J'utilise SCHED_FIFO\/SCHED_RR avec parcimonie et uniquement avec des limitations, afin d'\u00e9viter l'inversion de priorit\u00e9 ou la starvation.<\/p>\n\n<h2>Politiques de m\u00e9moire et masques NUMA<\/h2>\n\n<p>En ce qui concerne la politique de stockage, je fais une distinction entre l'allocation locale pr\u00e9f\u00e9rentielle, l'entrelacement sur plusieurs n\u0153uds et les masques NUMA fixes via cpuset.mems, afin que <strong>RAM<\/strong> va l\u00e0 o\u00f9 les threads fonctionnent r\u00e9ellement. Pour les services interactifs, je d\u00e9finis g\u00e9n\u00e9ralement \u201epreferred\u201c, ce qui permet au syst\u00e8me d'allouer localement et de ne d\u00e9vier qu'en cas de p\u00e9nurie, ce qui <strong>\u00c0 distance<\/strong>-Les acc\u00e8s sont limit\u00e9s. Les t\u00e2ches d'analyse ou de streaming profitent parfois de l'entrelacement, car la bande passante est r\u00e9partie sur les n\u0153uds et la pression sur un contr\u00f4leur diminue. Les masques fixes offrent un contr\u00f4le, mais exigent de la discipline dans la planification des capacit\u00e9s, afin d'\u00e9viter que des \u00e9v\u00e9nements OOM non souhait\u00e9s n'explosent dans un n\u0153ud, et <strong>Services<\/strong> peuvent perturber. Le tableau suivant attribue des politiques courantes \u00e0 des sc\u00e9narios typiques et aide \u00e0 prendre une d\u00e9cision rapide.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Politique<\/strong><\/th>\n      <th><strong>Effet<\/strong><\/th>\n      <th><strong>Charges de travail typiques<\/strong><\/th>\n      <th><strong>Risque<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Preferred (local)<\/td>\n      <td>RAM en priorit\u00e9 dans le n\u0153ud local, option de secours en cas de p\u00e9nurie<\/td>\n      <td>Web\/ API, caches, bases de donn\u00e9es OLTP<\/td>\n      <td>L\u00e9g\u00e8re d\u00e9rive \u00e0 pleine charge sur d'autres n\u0153uds<\/td>\n    <\/tr>\n    <tr>\n      <td>Interleave<\/td>\n      <td>R\u00e9partition uniforme sur des n\u0153uds s\u00e9lectionn\u00e9s<\/td>\n      <td>Streaming, analyse, grands scans<\/td>\n      <td>Latence plus \u00e9lev\u00e9e pour les acc\u00e8s individuels<\/td>\n    <\/tr>\n    <tr>\n      <td>Masque fixe NUMA<\/td>\n      <td>Lien strict avec des n\u0153uds de m\u00e9moire d\u00e9finis<\/td>\n      <td>Services strictement encapsul\u00e9s, tests d\u00e9terministes<\/td>\n      <td>Risque d'OOM en cas de mauvaise planification du budget<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Garde un \u0153il sur les commutateurs \u00e0 l'\u00e9chelle du syst\u00e8me : <strong>zone_reclaim_mode<\/strong> influence si un n\u0153ud nettoie agressivement sa propre m\u00e9moire avant d'allouer \u00e0 distance - ce qui est souvent ind\u00e9sirable pour les chemins de latence. <strong>Pages transparentes volumineuses<\/strong> (THP) peuvent d\u00e9clencher des migrations de pages ou g\u00e9n\u00e9rer des d\u00e9crochages ; pour les services sensibles \u00e0 la latence, je choisis g\u00e9n\u00e9ralement \u201emadvise\u201c et utilise des hugepages statiques lorsque c'est judicieux, afin d'augmenter les occurrences TLB et de r\u00e9duire les pics de d\u00e9faut de page.<\/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\/server_performance_optimization_2314.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lier les chemins du r\u00e9seau et des E\/S \u00e0 proximit\u00e9 du n\u0153ud<\/h2>\n\n<p>J'aligne les queues de NIC (RX\/ TX) de telle sorte que leurs IRQ pointent vers les noyaux du n\u0153ud appropri\u00e9 et que le traitement des paquets se fasse l\u00e0 o\u00f9 les <strong>App<\/strong> calculent. Il en va de m\u00eame pour les SSD NVMe ou les contr\u00f4leurs RAID : les threads d'E\/S doivent \u00eatre ex\u00e9cut\u00e9s sur le n\u0153ud auquel le p\u00e9riph\u00e9rique est connect\u00e9 par PCIe, afin que les chemins DMA restent courts et que le syst\u00e8me ne soit pas endommag\u00e9. <strong>Bottlenecks<\/strong> ne se produisent pas. Sous Linux, j'ajuste les masques d'affinit\u00e9 IRQ et je les associe aux pools d'unit\u00e9s centrales de mes services afin de cr\u00e9er un chemin continu. En cas de micro-bursts provenant du r\u00e9seau, par exemple de nombreux handshakes TLS, cette proximit\u00e9 est directement payante, car les chemins de copie sont plus courts et les caches CPU restent chauds, et <strong>Contexte<\/strong> ne bascule que rarement. Il en r\u00e9sulte un flux de donn\u00e9es coh\u00e9rent du paquet \u00e0 l'application jusqu'au stockage, sans sauts de n\u0153uds inutiles.<\/p>\n\n<p>Leviers concrets dans la pile r\u00e9seau : <strong>RSS<\/strong> pour la distribution de mat\u00e9riel sur les files d'attente, <strong>RPS\/RFS<\/strong> pour la commande de l'unit\u00e9 centrale c\u00f4t\u00e9 logiciel et <strong>XPS<\/strong> pour la s\u00e9lection TX. Avec ethtool, j'attribue aux queues RX des groupes de base qui fonctionnent dans le m\u00eame n\u0153ud que tes travailleurs. Pour le stockage, je mise sur <strong>blk-mq<\/strong>-Les contr\u00f4leurs NVMe offrent plusieurs files d'attente de soumission\/compl\u00e9tion que je mets \u00e0 l'\u00e9chelle et affine \u2264 nombre de c\u0153urs par n\u0153ud. V\u00e9rifie r\u00e9guli\u00e8rement si les interruptions (cat \/proc\/interrupts) tirent l\u00e0 o\u00f9 se trouvent les c\u0153urs de ton app - tu peux reconna\u00eetre une d\u00e9rive \u00e0 l'augmentation des octets distants malgr\u00e9 une charge stable.<\/p>\n\n<h2>Structurer l'architecture de l'application en fonction de la NUMA<\/h2>\n\n<p>Au niveau de l'application, je cr\u00e9e mes propres pools de travail pour chaque n\u0153ud NUMA, je garde les files d'attente locales et j'\u00e9vite les points de verrouillage globaux afin que <strong>Fils de discussion<\/strong> ne pas faire de sauts crois\u00e9s. Je configure le sharding de sessions et de donn\u00e9es de mani\u00e8re \u00e0 ce que les partitions chaudes restent l\u00e0 o\u00f9 les travailleurs demandeurs sont en cours d'ex\u00e9cution et que les partitions froides restent l\u00e0 o\u00f9 les travailleurs sont en cours d'ex\u00e9cution. <strong>Temps<\/strong> ne se perde pas dans le trafic inter-n\u0153uds. Pour les caches, j'ai plus souvent recours \u00e0 des r\u00e9plicats plut\u00f4t qu'\u00e0 une instance centrale, afin que les lecteurs rencontrent des copies locales des n\u0153uds. Dans Netty, Tokyo, libuv ou les clients DB, j'attache des boucles d'\u00e9v\u00e9nements \u00e0 des noyaux fixes et je fais attention \u00e0 la proximit\u00e9 de l'IRQ afin de limiter les changements de t\u00e2ches et de permettre aux clients de se concentrer sur leur travail. <strong>Caches<\/strong> mieux viser. Cette disposition r\u00e9duit les effets de ping-pong et rend les temps de r\u00e9action plus constants au cours de la journ\u00e9e.<\/p>\n\n<p>Un levier sous-estim\u00e9 sont <strong>Allocateur<\/strong> et des options d'ex\u00e9cution : Les allocateurs compatibles NUMA (jemalloc\/tcmalloc) r\u00e9duisent la contention des threads crois\u00e9s et gardent les pages plus proches des noyaux parents des threads. Dans les piles JVM, des options telles que la conscience NUMA et la pr\u00e9-tache aident les phases de d\u00e9faut d\u00e9terministes ; en .NET, j'aligne les threads GC pr\u00e8s des n\u0153uds et je fais attention au GC du serveur pour lisser les temps d'arr\u00eat. En Go, je dimensionne GOMAXPROCS par pool de n\u0153uds et je tiens les ordonnanceurs de goroutine \u00e0 l'\u00e9cart des noyaux de latence qui fonctionnent \u00e0 proximit\u00e9 de l'IRQ.<\/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\/server_performance_desk_7452.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>G\u00e9rer judicieusement l'auto-\u00e9quilibrage de la NUMA<\/h2>\n\n<p>Les m\u00e9canismes d'\u00e9quilibrage automatique NUMA du noyau peuvent aider \u00e0 lisser la charge distribu\u00e9e, mais je v\u00e9rifie toujours s'ils ne d\u00e9passent pas mes capacit\u00e9s. <strong>Affinity<\/strong> de l'activit\u00e9 de l'utilisateur. Dans les services \u00e0 latence critique, je d\u00e9sactive ou j'\u00e9trangle le d\u00e9placement automatique s'il arrache des threads \u00e0 leur m\u00e9moire locale et <strong>Pointes<\/strong> est g\u00e9n\u00e9r\u00e9. Pour les t\u00e2ches d'analyse ou le traitement par lots, j'ai tendance \u00e0 laisser l'\u00e9quilibrage activ\u00e9, car il permet d'augmenter la bande passante sans d\u00e9grader l'interaction. Une introduction pratique aux strat\u00e9gies d'\u00e9quilibrage me fournit des points de d\u00e9part suppl\u00e9mentaires : <a href=\"https:\/\/webhosting.de\/fr\/numa-balancing-serveur-optimisation-de-la-memoire-materiel-numaflux\/\">Comprendre l'\u00e9quilibrage NUMA<\/a> montre quand l'automatisme porte et quand il faut attribuer manuellement. En fin de compte, je d\u00e9cide en fonction des donn\u00e9es par classe de service, au lieu d'appliquer aveugl\u00e9ment un pr\u00e9r\u00e9glage global et d'utiliser les donn\u00e9es de la classe de service. <strong>Objectifs<\/strong> de manquer.<\/p>\n\n<p>Lorsque l'\u00e9quilibrage est activ\u00e9, j'observe les taux de migration, les pics de d\u00e9fauts mineurs\/majeurs et le steal CPU par n\u0153ud. Si des pages sont d\u00e9plac\u00e9es de mani\u00e8re cyclique, je contrebalance avec un \u00e9pinglage plus ferme, un pr\u00e9-touch et des masques de m\u00e9moire plus \u00e9troits. Dans les charges de travail avec de longs balayages s\u00e9quentiels, l'\u00e9quilibrage peut en revanche harmoniser la charge, \u00e0 condition qu'aucun chemin de latence interactif ne soit concern\u00e9.<\/p>\n\n<h2>Monitoring : mesurer, comparer, d\u00e9cider<\/h2>\n\n<p>Sans mesure, le r\u00e9glage reste un jeu de devinettes, c'est pourquoi j'effectue un suivi de la charge CPU par c\u0153ur et par n\u0153ud, de l'utilisation de la m\u00e9moire par n\u0153ud et de la part de la m\u00e9moire utilis\u00e9e par les n\u0153uds. <strong>\u00c0 distance<\/strong>-acc\u00e8s aux donn\u00e9es. Pour l'exp\u00e9rience de l'utilisateur, les latences P95\/ P99 comptent nettement plus que les valeurs moyennes, car les valeurs aberrantes marquent l'impression SLA et <strong>Co\u00fbts<\/strong> poussent vers le haut. Je r\u00e9alise des profils de charge proches de la r\u00e9alit\u00e9 avec des caches froids et chauds, car les deux mondes pr\u00e9sentent des goulots d'\u00e9tranglement diff\u00e9rents. Apr\u00e8s chaque modification, je documente les param\u00e8tres, la date du test et les r\u00e9sultats, afin de pouvoir revenir en arri\u00e8re plus tard en toute s\u00e9curit\u00e9. <strong>Connaissances<\/strong> ne soit pas perdue. En outre, si l'on met en corr\u00e9lation les m\u00e9triques des applications - longueurs de file d'attente, retours, collecte de d\u00e9chets - avec les valeurs du syst\u00e8me, on identifie plus rapidement les causes et les effets.<\/p>\n\n<p>Aides pratiques dans l'analyse :<\/p>\n<ul>\n  <li>numastat (par syst\u00e8me et par processus) pour local vs. <strong>\u00c0 distance<\/strong>-conclusion<\/li>\n  <li>\/proc\/interrupts et temps de SoftIRQ par CPU pour d\u00e9rive d'IRQ<\/li>\n  <li>\u00e9v\u00e9nements perf et statistiques de l'ordonnanceur pour la profondeur de la file d'attente, les changements de contexte, les \u00e9checs LLC<\/li>\n  <li>fio\/iperf\/wrk avec des pools de travail sp\u00e9cifiques aux n\u0153uds pour des comparaisons reproductibles<\/li>\n<\/ul>\n<p>L'\u00e9valuation se fait par n\u0153ud : Je m'attends \u00e0 ce que les histogrammes de latence soient tr\u00e8s proches les uns des autres. Si un n\u0153ud s'\u00e9loigne vers le haut, je recherche d'abord une charge d'IRQ mal r\u00e9partie, une d\u00e9rive dans le cache de la page ou des tas qui ont \u00e9t\u00e9 allou\u00e9s au mauvais n\u0153ud lors de l'\u00e9chauffement.<\/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\/hosting-serverraum-8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA dans les VM et les conteneurs<\/h2>\n\n<p>En virtualisation, le placement de vCPU et de vRAM sur un n\u0153ud commun compte pour que les charges de travail invit\u00e9es ne s'effilochent pas et <strong>Latence<\/strong> est en train de monter en puissance. Je dimensionne la RAM de mani\u00e8re \u00e0 ce qu'elle tienne dans le n\u0153ud local et j'\u00e9vite les grosses VM qui s'\u00e9tendent sur plusieurs n\u0153uds, et <strong>D\u00e9rive<\/strong> d\u00e9clencher le processus. Pour les conteneurs, j'utilise des contr\u00f4leurs cpuset afin que les groupes de pods travaillent de mani\u00e8re coh\u00e9rente sur un n\u0153ud et que le stockage soit cr\u00e9\u00e9 localement. Je place de pr\u00e9f\u00e9rence les invit\u00e9s charg\u00e9s d'E\/S sur le n\u0153ud avec une connexion directe au stockage, afin de r\u00e9duire les trajets DMA et d'\u00e9viter les erreurs. <strong>IRQ<\/strong>-bruit, en r\u00e9duisant le bruit. Ainsi, m\u00eame les h\u00f4tes de virtualisation denses restent pr\u00e9visibles et portent plus de projets sur le m\u00eame mat\u00e9riel.<\/p>\n\n<p>Je fais attention \u00e0 <strong>vNUMA<\/strong>-Expos\u00e9 : l'invit\u00e9 doit voir la m\u00eame structure de n\u0153uds que celle fournie physiquement par l'hyperviseur. L'\u00e9pinglage vCPU et la liaison vRAM vont de pair ; je d\u00e9place si possible les ajouts \u00e0 chaud pendant les fen\u00eatres de maintenance, car sinon les nouvelles pages atterrissent \u00e0 distance. Dans Kubernetes, je r\u00e8gle la QoS sur \u201eGuaranteed\u201c, le gestionnaire de CPU sur \u201estatic\u201c et le placement conscient de la topologie, afin que les pods ne se d\u00e9placent pas sur les n\u0153uds. Pour les SR-IOV\/VF, j'attribue les VF au n\u0153ud physique appropri\u00e9 et je lie les files d'attente IRQ aux ensembles de CPU des pods ou des VM qu'ils desservent.<\/p>\n\n<h2>Pr\u00e9parer le First-Touch, le Warmup et le Heaps de mani\u00e8re cibl\u00e9e<\/h2>\n\n<p>De nombreuses erreurs de performance surviennent lors <strong>Lancement<\/strong>Pendant la phase d'\u00e9chauffement, les tas se d\u00e9veloppent l\u00e0 o\u00f9 les premi\u00e8res requ\u00eates atterrissent - souvent de mani\u00e8re centralis\u00e9e sur un n\u0153ud. C'est pourquoi je proc\u00e8de \u00e0 des \u00e9chauffements contr\u00f4l\u00e9s par n\u0153ud : je d\u00e9marre les instances avec un masque CPU\/m\u00e9moire d\u00e9fini, j'ex\u00e9cute des requ\u00eates de pr\u00e9chargement cibl\u00e9es et j'initialise les caches en parall\u00e8le par n\u0153ud. Pour les services JVM, j'active la pr\u00e9-tache du tas ; pour les bases de donn\u00e9es, je segmente les pools de tampons par n\u0153ud. Cela permet de r\u00e9duire les migrations de pages ult\u00e9rieures et de veiller \u00e0 ce que les premi\u00e8res requ\u00eates ne marquent pas la r\u00e9partition de la m\u00e9moire de mani\u00e8re al\u00e9atoire.<\/p>\n\n<h2>R\u00e9glage du noyau\/BIOS pour des latences constantes<\/h2>\n\n<p>Sous le capot, j'ajuste la politique d'alimentation et d'interruption :<\/p>\n<ul>\n  <li>Gouverneur CPU sur \u201eperformance\u201c, limiter les C-States profonds, utiliser les C-States de package avec prudence pour <strong>Jitter<\/strong> de r\u00e9duire.<\/li>\n  <li>Ne pas limiter la fr\u00e9quence de la m\u00e9moire ; les profils d'\u00e9nergie \u00e9quilibr\u00e9s r\u00e9duisent souvent la fr\u00e9quence de la m\u00e9moire. <strong>D\u00e9bit<\/strong> en charge.<\/li>\n  <li>\u00c9viter la modulation Spread-Spectrum\/Clock si la coh\u00e9rence est plus importante qu'une \u00e9conomie d'\u00e9nergie minimale.<\/li>\n<\/ul>\n<p>Au niveau du noyau, je garde les unit\u00e9s centrales de maintenance s\u00e9par\u00e9es des noyaux de latence, je minimise les interruptions de temporisateur sur les noyaux chauds (nohz_full) et je parque les t\u00e2ches d'arri\u00e8re-plan (compaction, Kswapd) de pr\u00e9f\u00e9rence sur les noyaux syst\u00e8me d'un n\u0153ud qui n'emprunte pas de chemins de latence.<\/p>\n\n<h2>D\u00e9pannage et anti-patterns typiques<\/h2>\n\n<ul>\n  <li><strong>Sympt\u00f4me<\/strong>: La latence du P99 saute apr\u00e8s les d\u00e9ploiements. <strong>Cause<\/strong>: heaps\/caches first-touch sur le mauvais node. <strong>Solution<\/strong>: Warmup\/Pre-Touch sous Affinity cible, puis ouvrir l'\u00e9quilibreur de charge.<\/li>\n  <li><strong>Sympt\u00f4me<\/strong>: temps de SoftIRQ \u00e9lev\u00e9 sur les \u201emauvais\u201c CPU. <strong>Cause<\/strong>irqbalance r\u00e9partie sur les n\u0153uds. <strong>Solution<\/strong>: Fixer l'affinit\u00e9 IRQ, mettre le n\u0153ud RPS\/RFS\/XPS en conformit\u00e9.<\/li>\n  <li><strong>Sympt\u00f4me<\/strong>OOM dans un n\u0153ud, bien que la RAM syst\u00e8me soit libre. <strong>Cause<\/strong>: Masque NUMA strict sans tampon. <strong>Solution<\/strong>Corriger la capacit\u00e9 ou l'utiliser de mani\u00e8re pr\u00e9f\u00e9rentielle, \u00e9tablir des alertes par n\u0153ud.<\/li>\n  <li><strong>Sympt\u00f4me<\/strong>: D\u00e9bit irr\u00e9gulier avec NVMe. <strong>Cause<\/strong>: Mauvais mappage de la file d'attente, file d'attente partag\u00e9e cross-node. <strong>Solution<\/strong>: files blk-mq\/NVMe par n\u0153ud, threads d'E\/S pinnnen.<\/li>\n<\/ul>\n\n<h2>Liste de contr\u00f4le pratique<\/h2>\n\n<ul>\n  <li>Enregistrer la topologie : N\u0153uds, c\u0153urs, RAM, p\u00e9riph\u00e9riques PCIe par socket.<\/li>\n  <li>Dessiner une coupe de service : Quels sont les chemins <strong>Latence<\/strong>-critique, quel batchig ?<\/li>\n  <li>D\u00e9finir l'affinit\u00e9 CPU\/M\u00e9moire par classe ; respecter la premi\u00e8re touche au d\u00e9marrage.<\/li>\n  <li>Lier les IRQ\/Queues \u00e0 proximit\u00e9 des n\u0153uds ; v\u00e9rifier les queues RSS\/RPS\/XPS et NVMe.<\/li>\n  <li>Surveillance sur P95\/P99, acc\u00e8s \u00e0 distance, file d'attente d'ex\u00e9cution, distribution d'IRQ.<\/li>\n  <li>Contr\u00f4ler l'\u00e9quilibrage automatique de mani\u00e8re cibl\u00e9e ; choisir THP\/zone_reclaim_mode de mani\u00e8re appropri\u00e9e.<\/li>\n  <li>Dans les VM\/conteneurs, maintenir la coh\u00e9rence de vNUMA, de l'\u00e9pinglage vCPU et de la liaison vRAM.<\/li>\n  <li>Tester de mani\u00e8re it\u00e9rative, documenter, reculer en cas de d\u00e9rive et ajuster plus finement.<\/li>\n<\/ul>\n\n<h2>Bilan succinct et feuille de route pour le tuning<\/h2>\n\n<p>C'est l\u00e0 que le rendement est le plus \u00e9lev\u00e9, <strong>Fils de discussion<\/strong> et la m\u00e9moire, de raccourcir les chemins d'E\/S et de les r\u00e9partir avec pr\u00e9caution. Je commence par une analyse topologique, je planifie les services n\u0153ud par n\u0153ud, je d\u00e9finis l'affinit\u00e9 CPU et m\u00e9moire, je connecte le r\u00e9seau\/le stockage de mani\u00e8re appropri\u00e9e et j'observe les valeurs P95\/P99 en me concentrant sur <strong>\u00c0 distance<\/strong>-acc\u00e8s au r\u00e9seau. Ensuite, j'affine la taille des pools, les masques IRQ et les politiques jusqu'\u00e0 ce que les pics de latence diminuent et que le d\u00e9bit augmente. Pour les VM et les conteneurs, je v\u00e9rifie le placement s\u00e9par\u00e9ment, car l'hyperviseur a beaucoup d'influence et <strong>Fronti\u00e8res<\/strong> agissent diff\u00e9remment. En r\u00e9p\u00e9tant ce processus et en le documentant, on obtient des performances nettement plus \u00e9lev\u00e9es du serveur NUMA Locality et de la m\u00e9moire CPU Affinity - souvent \u00e0 un prix inf\u00e9rieur \u00e0 celui de la mise \u00e0 niveau de mat\u00e9riel suppl\u00e9mentaire en euros.<\/p>","protected":false},"excerpt":{"rendered":"<p>Apprends comment Server NUMA Locality et CPU-Memory Affinity optimisent les performances de ton h\u00e9bergement. Le guide montre comment r\u00e9gler les performances des serveurs modernes de mani\u00e8re pratique.<\/p>","protected":false},"author":1,"featured_media":19858,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19865","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":"67","_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":"Server NUMA","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":"19858","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19865","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=19865"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19865\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/19858"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=19865"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=19865"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=19865"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}