{"id":20634,"date":"2026-08-14T11:50:07","date_gmt":"2026-08-14T09:50:07","guid":{"rendered":"https:\/\/webhosting.de\/numa-memory-policies-datenbankserver-optimierung-server\/"},"modified":"2026-08-14T11:50:07","modified_gmt":"2026-08-14T09:50:07","slug":"politiques-de-memoire-numa-optimisation-des-serveurs-de-bases-de-donnees-serveurs","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/numa-memory-policies-datenbankserver-optimierung-server\/","title":{"rendered":"Politiques de m\u00e9moire NUMA pour les grands serveurs de bases de donn\u00e9es : optimisation cibl\u00e9e des performances"},"content":{"rendered":"<p><strong>M\u00e9moire NUMA<\/strong> Pour les grands serveurs de bases de donn\u00e9es, cela d\u00e9termine \u00e0 quelle distance les threads op\u00e8rent par rapport \u00e0 la m\u00e9moire requise et dans quelle mesure les latences influencent les temps de r\u00e9ponse et le d\u00e9bit. J'adapte de mani\u00e8re cibl\u00e9e l'affectation des c\u0153urs de processeur, le placement en m\u00e9moire et la taille de la charge de travail, je r\u00e9duis les acc\u00e8s distants et j'obtiens ainsi une solution fiable et pr\u00e9visible <strong>Performance<\/strong>.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>Topologie<\/strong> Comprendre : prendre en compte de mani\u00e8re cibl\u00e9e les n\u0153uds, les c\u0153urs, la m\u00e9moire vive (RAM) et les interconnexions.<\/li>\n  <li><strong>Politiques<\/strong> Choisir l'option appropri\u00e9e : \u00ab Strict \u00bb, \u00ab Preferred \u00bb ou \u00ab Interleave \u00bb en fonction de l'objectif de la charge de travail.<\/li>\n  <li><strong>affinit\u00e9<\/strong> Mise en \u0153uvre : liaison locale des threads, des IRQ et de la m\u00e9moire.<\/li>\n  <li><strong>VMs<\/strong> au niveau du n\u0153ud : affecter les vCPU et la m\u00e9moire RAM \u00e0 un n\u0153ud NUMA.<\/li>\n  <li><strong>Suivi<\/strong> Effectuer : mesurer les lectures \u00e0 distance, la latence P99 et la charge des n\u0153uds.<\/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\/08\/datenbankserver-setup-8273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprendre la topologie NUMA<\/h2>\n<p>Je commence chaque optimisation par la <strong>Topologie<\/strong>: Combien y a-t-il de n\u0153uds NUMA, comment les c\u0153urs sont-ils r\u00e9partis, comment la m\u00e9moire vive est-elle connect\u00e9e aux sockets, et quel est le co\u00fbt des acc\u00e8s inter-n\u0153uds ? L'acc\u00e8s \u00e0 la m\u00e9moire locale prend nettement moins de temps qu'un acc\u00e8s au-del\u00e0 des limites d'un n\u0153ud, c'est pourquoi j'\u00e9vite les <strong>\u00c0 distance<\/strong>-m\u00e9thodes. Les grands serveurs de bases de donn\u00e9es tirent profit d'une planification des charges de travail qui permet de maintenir les threads et les donn\u00e9es sur le m\u00eame n\u0153ud. Si le volume de donn\u00e9es actives ne tient pas dans un seul n\u0153ud, je planifie d\u00e9lib\u00e9r\u00e9ment la r\u00e9partition plut\u00f4t que de m'en remettre au comportement par d\u00e9faut. C'est ainsi que je maintiens la <strong>Latence<\/strong> faible et permet un d\u00e9bit r\u00e9gulier, m\u00eame en cas de charge \u00e9lev\u00e9e.<\/p>\n\n<h3>Choisir correctement les param\u00e8tres du BIOS et de la configuration mat\u00e9rielle<\/h3>\n<p>Je v\u00e9rifie dans le BIOS que <strong>Entrelacement de n\u0153uds<\/strong> est d\u00e9sactiv\u00e9e afin de pr\u00e9server la s\u00e9paration NUMA. Je r\u00e9partis les canaux de m\u00e9moire de mani\u00e8re sym\u00e9trique par socket et je veille \u00e0 la configuration (1DPC vs 2DPC) afin d'\u00e9viter toute baisse inutile de la fr\u00e9quence d'horloge et de la bande passante. Des fonctionnalit\u00e9s telles que <strong>\u00c9tats C<\/strong> Et pour les modes d'\u00e9conomie d'\u00e9nergie agressifs, je r\u00e8gle les objectifs de latence de mani\u00e8re plus prudente, afin que les c\u0153urs n'aient pas \u00e0 se r\u00e9veiller sans cesse. <strong>SMT\/hyper-threading<\/strong> J'\u00e9value cela en fonction de la charge de travail : pour les charges de travail OLTP fortement d\u00e9pendantes de la m\u00e9moire, je limite le nombre de threads SMT actifs en parall\u00e8le par c\u0153ur afin de r\u00e9duire la pression sur le cache et la variabilit\u00e9. Je v\u00e9rifie \u00e9galement que les p\u00e9riph\u00e9riques PCIe (cartes r\u00e9seau, NVMe) sont connect\u00e9s localement par socket, afin que leur <strong>IRQs<\/strong> et que les chemins DMA ne traversent pas l'interconnexion. En mettant en place une configuration rigoureuse \u00e0 ce niveau, on jette les bases sur lesquelles les politiques et les affinit\u00e9s peuvent produire leurs effets.<\/p>\n\n<h2>Bien choisir les politiques de m\u00e9moire<\/h2>\n<p>Le choix de la <strong>Politique<\/strong> d\u00e9termine \u00e0 partir de quel n\u0153ud le noyau alloue de la m\u00e9moire et comment fonctionnent les solutions de repli. Le param\u00e8tre \u00ab Strict \u00bb fixe des limites strictes et interrompt les allocations si le n\u0153ud cible ne dispose pas d'espace suffisant ; cela donne la priorit\u00e9 \u00e0 <strong>Performance<\/strong> En mati\u00e8re de flexibilit\u00e9. Le mode \u00ab Preferred \u00bb privil\u00e9gie un n\u0153ud, mais se rabat sur d'autres en cas de p\u00e9nurie, offrant ainsi un juste milieu. Le mode \u00ab Interleave \u00bb r\u00e9partit les pages selon le principe du \u00ab round-robin \u00bb entre plusieurs n\u0153uds, ce qui peut s\u2019av\u00e9rer judicieux pour des volumes de donn\u00e9es tr\u00e8s importants et utilis\u00e9s de mani\u00e8re uniforme. Pour de nombreuses bases de donn\u00e9es, une strat\u00e9gie locale utilisant \u00ab Preferred \u00bb ou \u00ab Strict \u00bb est g\u00e9n\u00e9ralement la meilleure solution. <strong>Choix<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Politique<\/th>\n      <th>Conduite<\/th>\n      <th>Utilisation typique<\/th>\n      <th>Avantages<\/th>\n      <th>Risques<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Strict<\/td>\n      <td>Utilise uniquement la m\u00e9moire du n\u0153ud cible, sinon une erreur se produit<\/td>\n      <td>Critique latente <strong>Bases de donn\u00e9es<\/strong> avec une planification claire des n\u0153uds<\/td>\n      <td>Au maximum local <strong>Acc\u00e8s<\/strong>, latences pr\u00e9visibles<\/td>\n      <td>L'allocation peut \u00e9chouer si le n\u0153ud est plein<\/td>\n    <\/tr>\n    <tr>\n      <td>Pr\u00e9f\u00e9r\u00e9<\/td>\n      <td>N\u0153ud pr\u00e9f\u00e9r\u00e9, possibilit\u00e9 de basculer vers d'autres<\/td>\n      <td>G\u00e9n\u00e9ralit\u00e9s <strong>Charges de travail<\/strong> avec une charge variable<\/td>\n      <td>Une bonne proximit\u00e9 et une flexibilit\u00e9 acceptable<\/td>\n      <td>Augmentation du t\u00e9l\u00e9travail en p\u00e9riode de p\u00e9nurie<\/td>\n    <\/tr>\n    <tr>\n      <td>Interleave<\/td>\n      <td>Round-robin sur plusieurs n\u0153uds<\/td>\n      <td>Tr\u00e8s vaste, largement utilis\u00e9 <strong>Donn\u00e9es<\/strong><\/td>\n      <td>R\u00e9partition de la charge entre plusieurs n\u0153uds<\/td>\n      <td>Localisation moins favorable, latence potentiellement plus \u00e9lev\u00e9e<\/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\/08\/NUMA_Optimierung_Besprechung_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Threads, affinit\u00e9 CPU et liaison m\u00e9moire<\/h2>\n<p>Je mappe les threads aux c\u0153urs du n\u0153ud cible, je lie la m\u00e9moire avec numactl et j'aligne les IRQ de mani\u00e8re \u00e0 ce que <strong>Donn\u00e9es<\/strong> rester local. Cette combinaison entre l'affinit\u00e9 CPU et le \u00ab memory binding \u00bb r\u00e9duit les lectures \u00e0 distance co\u00fbteuses et resserre la distribution des temps d'ex\u00e9cution. Pour un contr\u00f4le granulaire, j'utilise des politiques au niveau des processus ou des threads et je maintiens le pool de tampons aussi pr\u00e8s que possible des threads de travail actifs. Si vous souhaitez approfondir le sujet, vous trouverez des \u00e9tapes pratiques pour <a href=\"https:\/\/webhosting.de\/fr\/serveur-numa-localite-cpu-memoire-affinity-optimisation-core\/\">Affinit\u00e9 avec le CPU<\/a>, qui peuvent \u00eatre appliqu\u00e9es directement sur des h\u00f4tes de production. C'est ainsi que je garantis la coh\u00e9rence <strong>Latence<\/strong> m\u00eame lorsque le syst\u00e8me est fortement sollicit\u00e9.<\/p>\n\n<h3>Donner la priorit\u00e9 aux Hotsets locaux<\/h3>\n<p>J'identifie les hotsets de la <strong>Charge de travail<\/strong> et je les place strictement localement, tandis que les donn\u00e9es froides peuvent \u00eatre stock\u00e9es de mani\u00e8re plus flexible. Gr\u00e2ce \u00e0 cette hi\u00e9rarchisation, je reste proche de la m\u00e9moire vive du n\u0153ud pour les chemins principaux. Lorsque la charge augmente, la solution s'adapte parfaitement, car les chemins co\u00fbteux continuent de s'ex\u00e9cuter localement. Sans cet ordre, la courbe de latence se d\u00e9grade d\u00e8s que les threads acc\u00e8dent de plus en plus souvent \u00e0 des donn\u00e9es situ\u00e9es sur d'autres n\u0153uds. Une <strong>Reliure<\/strong> emp\u00eache de mani\u00e8re fiable ce comportement pr\u00e9cis.<\/p>\n\n<h3>Fusionner le NUMA de stockage et le NUMA r\u00e9seau<\/h3>\n<p>Je classe <strong>NICs<\/strong> et <strong>NVMe<\/strong>-J'affecte de mani\u00e8re cibl\u00e9e les p\u00e9riph\u00e9riques aux sockets et redirige leurs IRQ vers les c\u0153urs locaux. Je maintiens la coh\u00e9rence du Receive\/Transmit Steering (RSS\/RPS\/XPS) par n\u0153ud, afin que les paquets soient trait\u00e9s l\u00e0 o\u00f9 s'ex\u00e9cutent les threads de la base de donn\u00e9es. Avec NVMe, j\u2019utilise plusieurs files d\u2019attente par c\u0153ur et j\u2019ancrage les threads d\u2019E\/S localement, afin que les chemins de journalisation et de donn\u00e9es ne transitent pas par l\u2019interconnexion. Pour la r\u00e9plication, je s\u00e9pare les chemins r\u00e9seau par n\u0153ud, afin que les flux WAL\/Redo entrants aboutissent localement. Ainsi, <strong>IO<\/strong>\u2013 et les chemins d'acc\u00e8s au processeur sont congruents, et la base de donn\u00e9es ne gaspille pas de cycles en effectuant des copies inutiles \u00e0 travers le r\u00e9seau de m\u00e9moire.<\/p>\n\n<h2>Planifier les machines virtuelles en fonction de la taille des n\u0153uds<\/h2>\n<p>Je dimensionne les machines virtuelles de mani\u00e8re \u00e0 ce que le nombre de vCPU et la m\u00e9moire vive tiennent dans un n\u0153ud NUMA physique, car cela permet de r\u00e9duire <strong>Latence<\/strong> et le trafic d'interconnexion. Les machines virtuelles \u201e Wide VMs \u00bb, dont la taille d\u00e9passe celle d'un n\u0153ud, r\u00e9partissent in\u00e9vitablement les acc\u00e8s \u00e0 la m\u00e9moire et perdent ainsi en pr\u00e9visibilit\u00e9. Lorsqu'une machine virtuelle doit \u00eatre plus grande, je planifie explicitement le vNUMA et veille \u00e0 une r\u00e9partition sym\u00e9trique entre les n\u0153uds. Du c\u00f4t\u00e9 de l\u2019h\u00f4te, j\u2019\u00e9vite la sursouscription pour les charges de travail sensibles \u00e0 la latence et je r\u00e9serve de la m\u00e9moire locale \u00e0 chaque VM. \u00ab \u00bb fournit un aper\u00e7u rapide de la structure physique des n\u0153uds.\u201e<a href=\"https:\/\/webhosting.de\/fr\/numa-nodes-server-hosting-grands-systemes-serverboost\/\">Planification des n\u0153uds NUMA<\/a>\u201c, ce qui facilite la prise de d\u00e9cision concernant la taille de la VM et <strong>Erreur<\/strong> lors de la mise en place.<\/p>\n\n<h3>Tenir compte des param\u00e8tres de l'hyperviseur<\/h3>\n<p>Je v\u00e9rifie la mani\u00e8re dont l'hyperviseur pr\u00e9sente le vNUMA et je conserve l'affectation des groupes de vCPU aux <strong>Noyaux<\/strong> de mani\u00e8re coh\u00e9rente. De plus, je veille \u00e0 ce que la topologie NUMA de la machine virtuelle corresponde \u00e0 celle de l'h\u00f4te, afin que le planificateur puisse rester local. Je limite autant que possible les r\u00e9servations de m\u00e9moire et les r\u00e8gles d'anti-affinit\u00e9, tout en les appliquant aussi strictement que n\u00e9cessaire. Je pr\u00e9f\u00e8re remplacer une forte densit\u00e9 de machines virtuelles sur un seul socket par une r\u00e9partition proche des n\u0153uds. C'est ainsi que je g\u00e8re <strong>\u00c0 distance<\/strong>- R\u00e9duis au minimum les acc\u00e8s et assure la stabilit\u00e9 des chemins d'E\/S.<\/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\/08\/numa-memory-policies-database-8672.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h3>Pratique des conteneurs et de l'orchestration<\/h3>\n<p>Dans les conteneurs, je mets <strong>cpuset<\/strong>- Limites coh\u00e9rentes : processeurs et masques de m\u00e9moire associ\u00e9s (<em>cpuset.cpus<\/em>, <em>cpuset.mems<\/em>) vont de pair. Les \u00ab systemd-slices \u00bb et les \u00ab units \u00bb se voient attribuer des affinit\u00e9s CPU fixes afin que le noyau applique bien la pr\u00e9f\u00e9rence de m\u00e9moire. Au niveau des couches d'orchestration, je pr\u00e9vois des pods\/services <strong>pr\u00e8s du n\u0153ud<\/strong>, j'utilise des \u00e9valuations topologiques et une allocation statique des c\u0153urs de processeur afin d'\u00e9viter qu'une charge de travail ne bascule d'un n\u0153ud \u00e0 l'autre. Je d\u00e9clare explicitement les Huge Pages par pod\/conteneur et je maintiens leur taille et leur nombre stables par n\u0153ud. Important : j\u2019affecte les processus d\u2019infrastructure et les processus secondaires (journalisation, sidecars, sauvegardes) \u00e0 d\u2019autres c\u0153urs, voire \u00e0 l\u2019autre n\u0153ud NUMA, afin de ne pas perturber les hotsets de la base de donn\u00e9es.<\/p>\n\n<h2>\u00c9quilibrage NUMA et optimisation du syst\u00e8me d'exploitation<\/h2>\n<p>L'\u00e9quilibrage NUMA automatique peut optimiser les ressources locales <strong>Acc\u00e8s<\/strong> am\u00e9liorer lorsque les charges de travail migrent ou que les phases changent radicalement. Je l'utilise de mani\u00e8re cibl\u00e9e, mais je v\u00e9rifie si le d\u00e9placement des pages dans un sens puis dans l'autre n'est pas plus g\u00eanant qu'utile. Les processus bien d\u00e9finis pr\u00e9sentant une affinit\u00e9 claire tirent souvent davantage profit de politiques d\u00e9finies manuellement que d\u2019un r\u00e9\u00e9quilibrage constant. Je v\u00e9rifie les param\u00e8tres du noyau, la gestion des IRQ et les Huge Pages transparentes au cas par cas, en fonction de la base de donn\u00e9es et de la plateforme. Ce document me sert de point de d\u00e9part : <a href=\"https:\/\/webhosting.de\/fr\/numa-balancing-serveur-optimisation-de-la-memoire-materiel-numaflux\/\">NUMA-Balancing<\/a>-Guide permettant de tester les param\u00e8tres \u00e9tape par \u00e9tape et de <strong>dispersion<\/strong> de r\u00e9duire les latences.<\/p>\n\n<h2>Utiliser les \u00ab Huge Pages \u00bb de mani\u00e8re cibl\u00e9e<\/h2>\n<p>J'utilise les \u00ab Huge Pages \u00bb pour r\u00e9duire les \u00e9checs de TLB et les grandes <strong>M\u00e9moire<\/strong>pour traiter plus efficacement ces zones. Pour les serveurs de bases de donn\u00e9es, je r\u00e9serve les pages \u00e0 l'avance, je les attribue \u00e0 des n\u0153uds et je v\u00e9rifie si l'instance les utilise r\u00e9ellement. Je d\u00e9sactive souvent les \u00ab Transparent Huge Pages \u00bb lorsque des objectifs de latence sont fix\u00e9s et je configure des \u00ab Huge Pages \u00bb statiques afin que l'allocation reste d\u00e9terministe. La proximit\u00e9 avec le n\u0153ud NUMA reste toutefois d\u00e9terminante ; les Huge Pages renforcent une bonne strat\u00e9gie, mais ne la remplacent pas. Ceux qui ignorent cela n'y gagnent pratiquement rien. <strong>Performance<\/strong> et s'expose \u00e0 des effets secondaires lors de la pagination.<\/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\/08\/numa_optimierung_7436.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionnement des bases de donn\u00e9es : pool de m\u00e9moire tampon et charge de travail<\/h2>\n<p>Je planifie le volume de travail actif de mani\u00e8re \u00e0 ce que le pool de tampons, les caches de verrouillage et de planification, ainsi que les \u00e9l\u00e9ments les plus sollicit\u00e9s <strong>tableaux<\/strong> tenir dans un n\u0153ud. Pour les instances de tr\u00e8s grande taille, je r\u00e9partis les services ou les shards entre les n\u0153uds, plut\u00f4t que de d\u00e9ployer une \u00e9norme instance monolithique sur l'ensemble des n\u0153uds. Pour les cas OLTP, je maintiens le pool de tampons par n\u0153ud \u00e0 un niveau compact et je donne la priorit\u00e9 aux taux de r\u00e9ussite locaux. Pour les analyses OLAP, l\u2019interleave peut s\u2019av\u00e9rer utile dans des cas particuliers, lorsque le volume de donn\u00e9es est gigantesque et homog\u00e8ne. Sans cette discipline, le <strong>Interconnexion<\/strong>-Le trafic et \u00e9puise les r\u00e9serves pr\u00e9cis\u00e9ment au moment o\u00f9 surviennent les pics de charge.<\/p>\n\n<h3>Astuces sp\u00e9cifiques aux bases de donn\u00e9es<\/h3>\n<p>Je tiens compte du mod\u00e8le de processus et de threads du moteur : <strong>PostgreSQL<\/strong> Comme cela utilise des processus, je configure l'instance principale, Autovacuum et Checkpointer s\u00e9par\u00e9ment pour chaque n\u0153ud et je conserve <em>shared_buffers<\/em> localement par shard. Pour <strong>MySQL\/InnoDB<\/strong> je classe <em>instances du pool de m\u00e9moire tampon<\/em> sur les n\u0153uds et aligne localement les threads d'E\/S et les modules d'\u00e9criture dans les journaux. <strong>Serveur SQL<\/strong> b\u00e9n\u00e9ficie d'un Soft-NUMA adapt\u00e9 et d'une allocation qui r\u00e9partit les planificateurs et les groupes de m\u00e9moire entre les n\u0153uds physiques. <strong>Oracle<\/strong>- Je configure les instances avec des \u00ab Large Pages \u00bb locales et je r\u00e9partis les serveurs de traitement et d'E\/S entre les n\u0153uds. De mani\u00e8re g\u00e9n\u00e9rale, je r\u00e9duis les conflits d'ar\u00e8ne de l'allocateur (par exemple jemalloc) gr\u00e2ce \u00e0 des ar\u00e8nes adapt\u00e9es \u00e0 la structure NUMA et je veille \u00e0 ce que <strong>Gestionnaire de verrouillage<\/strong> et que les points chauds de verrouillage restent localis\u00e9s, en effectuant un partitionnement et un sharding au niveau des n\u0153uds.<\/p>\n\n<h2>Suivi : les indicateurs qui comptent<\/h2>\n<p>Je mesure les lectures \u00e0 distance, le trafic d'interconnexion entre n\u0153uds, les erreurs de page par n\u0153ud et le P99-<strong>Latence<\/strong> des requ\u00eates concern\u00e9es. Je surveille \u00e9galement l'utilisation du processeur par n\u0153ud, les taux de NUMA Miss et la proportion d'acc\u00e8s \u00e0 la m\u00e9moire locale. Cette vue permet de d\u00e9terminer si la politique est efficace ou si des threads acc\u00e8dent de mani\u00e8re incontr\u00f4l\u00e9e \u00e0 des pages distantes. Je mets en corr\u00e9lation les pics avec les d\u00e9cisions du planificateur, les \u00e9v\u00e9nements de migration et les erreurs d\u2019allocation. Seules ces m\u00e9triques confirment que la <strong>Politique<\/strong> non seulement en laboratoire, mais aussi de mani\u00e8re permanente dans le syst\u00e8me de production.<\/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\/08\/numa_memory_optimierung_3481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Strat\u00e9gie de test et d\u00e9ploiement<\/h2>\n<p>Je proc\u00e8de \u00e0 des tests par \u00e9tapes : je commence par des micro-benchmarks pour <strong>Bande passante<\/strong> et la latence par n\u0153ud, puis des charges de travail r\u00e9alistes avec des caches \u00ab froids \u00bb et \u00ab chauds \u00bb. J'augmente progressivement les niveaux de charge, je mesure les valeurs P95\/P99\/P99,9 et j'observe la r\u00e9partition, pas seulement les moyennes. Je documente chaque modification (strat\u00e9gie, affinit\u00e9s, Huge Pages, redirection des IRQ) et je r\u00e9alise des tests A\/B dans des conditions identiques. Avant le d\u00e9ploiement, je d\u00e9finis <strong>Crit\u00e8res d'interruption<\/strong> et un plan de repli pour pouvoir revenir rapidement \u00e0 la configuration pr\u00e9c\u00e9dente en cas de r\u00e9gression. Un bref test de stabilisation sous charge continue permet de v\u00e9rifier <strong>D\u00e9rive<\/strong> et des migrations qui restent invisibles \u00e0 court terme.<\/p>\n\n<h2>Proc\u00e9dure \u00e9tape par \u00e9tape<\/h2>\n<p>Je commence par saisir les <strong>Topologie<\/strong>: nombre de n\u0153uds, affectation des c\u0153urs, canaux de m\u00e9moire et interconnexion. Je d\u00e9termine ensuite la charge de travail cible par n\u0153ud et v\u00e9rifie si les \u00ab hotsets \u00bb s\u2019y int\u00e8grent. \u00c0 l\u2019\u00e9tape suivante, je configure l\u2019affinit\u00e9 CPU, le routage des IRQ et le \u00ab memory binding \u00bb au niveau des processus ou des threads. Ensuite, j\u2019active ou d\u00e9sactive l\u2019\u00e9quilibrage NUMA en fonction de la dynamique de la charge de travail et, si n\u00e9cessaire, je r\u00e9serve des Huge Pages par n\u0153ud. Enfin, je v\u00e9rifie le r\u00e9sultat \u00e0 l\u2019aide de tests de charge reproductibles et je surveille <strong>Chiffres cl\u00e9s<\/strong> en fonctionnement continu.<\/p>\n\n<h2>Exemples concrets et obstacles<\/h2>\n<p>Une instance OLTP comportant de nombreuses transactions courtes gagne sensiblement en performance lorsque je configure les threads de travail et le pool de tampons sur un <strong>N\u0153uds<\/strong> et de d\u00e9finir \u201e Strict \u201c ou \u00ab Preferred \u00bb. Un entrep\u00f4t de donn\u00e9es avec des scans larges peut tirer parti de l'interleave si les donn\u00e9es sont utilis\u00e9es de mani\u00e8re tr\u00e8s homog\u00e8ne et si les n\u0153uds sont bien sollicit\u00e9s. Les machines virtuelles perdent sensiblement en pr\u00e9visibilit\u00e9 d\u00e8s qu\u2019elles d\u00e9passent les limites des n\u0153uds et que l\u2019hyperviseur alloue la m\u00e9moire de mani\u00e8re d\u00e9cal\u00e9e. Je constate souvent qu\u2019une seule machine virtuelle \u00ab \u00e9tendue \u00bb surcharge l\u2019interconnexion et ralentit ainsi les machines virtuelles voisines. Ces effets disparaissent d\u00e8s que je passe \u00e0 une configuration locale <strong>Affectation<\/strong> et que je revienne \u00e0 une configuration vNUMA propre.<\/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\/08\/serverraum-numa-9023.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sc\u00e9narios d'erreur et anti-mod\u00e8les<\/h2>\n<p>Avec <strong>Strict<\/strong> j'augmente le risque que les allocations \u00e9chouent et que le m\u00e9canisme OOM-Killer intervienne. C'est pourquoi je garde des marges disponibles sur le n\u0153ud cible, je surveille les \u00e9checs et je d\u00e9finis des solutions de repli (par exemple, un redimensionnement cibl\u00e9 en dehors des heures de pointe). Les pages transparentes g\u00e9antes dans le <em>always<\/em>Mode - provoquant des chemins de latence <strong>D\u00e9fragmentation<\/strong> et les \u00e9curies \u2013 j'utilise des r\u00e9servations statiques ou j'active THP <em>madvise<\/em>. L'\u00e9quilibrage NUMA automatique peut d\u00e9placer les pages d'un c\u00f4t\u00e9 \u00e0 l'autre en cas de charge oscillante ; si je d\u00e9tecte des ph\u00e9nom\u00e8nes de \u00ab page bounce \u00bb, je r\u00e9applique les r\u00e8gles manuellement. Dans les machines virtuelles, <strong>Ballooning<\/strong> et la compression de la m\u00e9moire, un v\u00e9ritable fl\u00e9au pour la pr\u00e9visibilit\u00e9 ; je d\u00e9sactive ces fonctions pour les bases de donn\u00e9es critiques. Je ne planifie les migrations en direct entre n\u0153uds que pendant les fen\u00eatres d'indisponibilit\u00e9, ou je transf\u00e8re d'abord les donn\u00e9es c\u00f4t\u00e9 base de donn\u00e9es afin d'\u00e9viter que l'interconnexion ne soit satur\u00e9e de mani\u00e8re secondaire.<\/p>\n\n<h2>Planification des capacit\u00e9s et croissance<\/h2>\n<p>Je pr\u00e9vois, par n\u0153ud, une <strong>R\u00e9serve<\/strong> Je configure 10 \u00e0 20 % pour les pics de charge, l'Autovacuum\/Compaction et les t\u00e2ches de maintenance p\u00e9riodiques. Si le volume de donn\u00e9es augmente, je commence par faire \u00e9voluer la capacit\u00e9 au niveau des n\u0153uds (shards\/services), plut\u00f4t que d'agrandir aveugl\u00e9ment l'ensemble du pool de tampons. J\u2019emp\u00eache toute \u201e croissance insidieuse \u201c en fixant des limites strictes par n\u0153ud et en mettant en place des alertes d\u00e8s que les taux de r\u00e9ussite locaux baissent ou que les parts \u00e0 distance augmentent. Dans mes projections pour les prochains trimestres, je tiens compte non seulement du volume de donn\u00e9es, mais aussi <strong>Taux de transaction<\/strong> et des r\u00e9partitions d'acc\u00e8s modifi\u00e9es, car celles-ci d\u00e9placent souvent les hotsets plus rapidement que les besoins en m\u00e9moire proprement dits. La plateforme reste ainsi stable, et les extensions s'effectuent de mani\u00e8re contr\u00f4l\u00e9e, sans sacrifier la localit\u00e9 NUMA.<\/p>\n\n<h2>Bilan succinct<\/h2>\n<p>J'optimise les grands serveurs de bases de donn\u00e9es en <strong>NUMA<\/strong>- Je combine de mani\u00e8re optimale la topologie, les politiques et la taille des charges de travail. L'allocation locale de m\u00e9moire permet de gagner ces millisecondes d\u00e9cisives, tandis que les acc\u00e8s \u00e0 distance impr\u00e9vus font grimper la latence P99. \u00c0 l'avenir, je pr\u00e9vois de planifier les machines virtuelles de mani\u00e8re \u00e0 ce qu'elles s'int\u00e8grent dans les n\u0153uds ou exploitent clairement le vNUMA. J\u2019utilise de mani\u00e8re cibl\u00e9e les param\u00e8tres du syst\u00e8me d\u2019exploitation, les affinit\u00e9s et les Huge Pages, j\u2019en v\u00e9rifie l\u2019impact et je ne d\u00e9ploie les modifications qu\u2019apr\u00e8s avoir effectu\u00e9 des mesures. Ceux qui suivent ces \u00e9tapes obtiennent les performances attendues <strong>Performance<\/strong> compos\u00e9 de mat\u00e9riel informatique moderne et garantit la rapidit\u00e9 et la fiabilit\u00e9 des plateformes, m\u00eame en cas de charge \u00e9lev\u00e9e.<\/p>","protected":false},"excerpt":{"rendered":"<p>Les politiques de m\u00e9moire NUMA optimisent les serveurs de bases de donn\u00e9es de grande envergure gr\u00e2ce \u00e0 l'allocation locale de m\u00e9moire, \u00e0 l'affinit\u00e9 CPU et \u00e0 un mat\u00e9riel serveur adapt\u00e9.<\/p>","protected":false},"author":1,"featured_media":20627,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20634","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":"115","_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 Memory","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":"20627","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20634","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=20634"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20634\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20627"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20634"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20634"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20634"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}