Serveur dédié bi-processeur : comprendre NUMA et répartir la charge sous Linux

NUMA : ce qui se passe dans un serveur dédié bi-processeur

Quand vous louez un serveur dédié chez un hébergeur comme ElypseCloud, vous disposez d'un serveur physique complet avec un accès root. Contrairement à un serveur VPS (serveur virtuel privé), à un hébergement mutualisé ou à une instance cloud, les ressources matérielles ne sont pas partagées : vous êtes seul sur la machine. Cette exclusivité vous donne la main sur la topologie matérielle du processeur, et sur un serveur bi-processeur, cette topologie s'appelle NUMA.

Un serveur dédié bi-processeur comme ceux de la gamme Xeon Gold ElypseCloud embarque deux processeurs physiques, chacun relié à ses propres barrettes de RAM DDR4 ECC via ses canaux mémoire. Sur un Xeon Gold 6230 en configuration bi-socket, cela donne 2 x 6 canaux, soit 12 canaux mémoire au total. Chaque serveur est livré avec un SSD de 1 To d'espace disque, une adresse IP dédiée (IPv4 + IPv6) et un hébergement en datacenter Equinix PA6 à Paris.

Cette architecture porte le nom de NUMA (Non-Uniform Memory Access). Chaque processeur forme un noeud NUMA (NUMA node). Un processeur accède à sa propre mémoire locale en quelques dizaines de nanosecondes. S'il doit lire de la mémoire rattachée à l'autre processeur (mémoire distante), la requête transite par le bus UPI (Ultra Path Interconnect) : la latence mémoire augmente et la bande passante disponible diminue.

Sur un serveur bi-processeur, le noyau Linux voit donc deux noeuds NUMA, un par socket. Un processus mal placé, qui tourne sur le noeud 0 mais alloue sa mémoire sur le noeud 1, subit un surcoût d'accès mémoire à chaque lecture et chaque écriture. Avec 40 coeurs et 80 threads répartis sur deux sockets, la topologie NUMA devient un levier de performance important pour la virtualisation (serveurs virtuels Proxmox, VMware ESXi), les bases de données et tout service d'hébergement gourmand en mémoire.

Vérifier la topologie NUMA avec lscpu

La commande lscpu est disponible sur toute distribution Linux sans installation supplémentaire (paquet util-linux). Connectez-vous en root (ou via sudo) et affichez la topologie CPU et les noeuds NUMA du serveur :

lscpu

Sur un serveur dédié bi-processeur Xeon Gold 6230, la sortie indique deux noeuds NUMA, chacun associé à 20 coeurs physiques (40 threads avec Hyper-Threading) :

NUMA node(s):          2
NUMA node0 CPU(s):     0-19,40-59
NUMA node1 CPU(s):     20-39,60-79

Les numéros de CPU correspondent aux threads logiques vus par le noyau Linux. Les threads 0-19 et 40-59 partagent le même processeur physique (noeud 0), les threads 20-39 et 60-79 sont sur le second processeur (noeud 1). Si votre serveur n'affiche qu'un seul noeud NUMA, vérifiez dans le BIOS/UEFI que l'option NUMA / Node Interleaving est bien désactivée (le mode interleaving masque la topologie).

Inspecter les noeuds avec numactl

L'outil numactl (paquet numactl sur Debian/Ubuntu) fournit un diagnostic plus détaillé que lscpu. Installez-le si nécessaire :

sudo apt install -y numactl

Puis affichez l'inventaire matériel des noeuds NUMA :

numactl --hardware

La sortie montre, pour chaque noeud, la quantité de mémoire totale et libre, la liste des CPU associés et la matrice de distances entre noeuds. Sur un serveur bi-processeur, cette matrice ressemble à :

node distances:
node   0   1
  0:  10  21
  1:  21  10

La valeur 10 représente un accès local (référence). La valeur 21 indique que l'accès à la mémoire de l'autre noeud coûte environ deux fois plus cher en latence. Ces distances sont normalisées par le BIOS via la table SLIT (System Locality Information Table).

Mesurer les allocations mémoire avec numastat

La commande numastat (fournie par le paquet numactl) affiche les statistiques d'allocation mémoire par noeud NUMA depuis le démarrage du serveur :

numastat

Les colonnes importantes :

Un ratio numa_miss / numa_hit élevé sur un noeud signale que des processus allouent régulièrement de la mémoire distante. C'est le signe qu'un épinglage NUMA améliorerait les performances. Vous pouvez aussi cibler un processus précis :

numastat -p $(pidof mysqld)

Épingler un processus sur un noeud NUMA

numactl permet de lancer un programme en le contraignant à un noeud précis, tant pour l'exécution CPU que pour l'allocation mémoire :

numactl --cpunodebind=0 --membind=0 ./mon-service

Avec cette commande, le processus mon-service ne s'exécutera que sur les coeurs du noeud 0 et n'allouera de la mémoire que sur le noeud 0. Cela garantit que chaque accès mémoire reste local et profite de la latence la plus basse possible.

Pour un service géré par systemd, ajoutez la directive dans l'unité :

[Service]
ExecStart=/usr/bin/numactl --cpunodebind=0 --membind=0 /usr/sbin/mon-service
# Ou via NUMAPolicy et NUMAMask (systemd >= 243) :
NUMAPolicy=bind
NUMAMask=0

systemd 243 et versions ultérieures proposent les directives NUMAPolicy et NUMAMask directement dans le fichier d'unité, sans dépendre du binaire numactl. Les valeurs possibles de NUMAPolicy sont default, preferred, bind, interleave et local.

Sur un serveur bi-processeur avec 40 coeurs, une bonne pratique consiste à répartir les services lourds entre les deux noeuds : par exemple, le serveur de bases de données sur le noeud 0 et les serveurs virtuels ou le serveur web sur le noeud 1. Pour surveiller la charge CPU par coeur et vérifier l'équilibre, consultez notre guide surveiller les ressources avec htop et btop.

NUMA et virtualisation : Proxmox VE, VMware ESXi

Un serveur dédié bi-processeur est souvent utilisé comme hyperviseur pour héberger des serveurs virtuels (machines virtuelles). Que vous utilisiez Proxmox VE ou VMware ESXi, la gestion NUMA conditionne les performances de chaque machine virtuelle et de chaque serveur virtuel que vous faites tourner.

Proxmox VE

Si vous utilisez votre serveur dédié bi-processeur comme hyperviseur avec Proxmox VE, l'option NUMA de chaque machine virtuelle contrôle la façon dont QEMU/KVM expose la topologie mémoire au système invité.

Pour activer NUMA sur une VM depuis l'interface Proxmox :

1. Ouvrir la VM dans l'interface web Proxmox ;
2. Aller dans Matériel > Processeurs ;
3. Cocher Enable NUMA ;
4. Configurer le nombre de sockets et de coeurs pour qu'il corresponde à un noeud physique.

En ligne de commande, cela revient à ajouter numa: 1 dans le fichier de configuration de la VM (/etc/pve/qemu-server/<vmid>.conf) :

numa: 1
sockets: 1
cores: 20

Quand NUMA est activé, Proxmox tente de placer les vCPU et la mémoire d'une VM sur le même noeud physique. Le système invité voit lui aussi la topologie NUMA, ce qui permet à son propre ordonnanceur de prendre de meilleures décisions de placement. L'activation de NUMA est également un prérequis pour le hotplug de CPU et de mémoire dans Proxmox.

Pour les VM dont la charge dépasse un seul noeud (plus de 20 coeurs ou plus de la moitié de la RAM), configurez deux sockets virtuels avec NUMA activé pour que le système invité gère lui-même la répartition entre les noeuds, comme il le ferait sur un serveur physique bi-processeur.

VMware ESXi

VMware ESXi gère le placement NUMA automatiquement via son ordonnanceur. ESXi tente de placer chaque serveur virtuel entièrement dans un seul noeud NUMA. Si une VM nécessite plus de ressources qu'un noeud n'en offre, ESXi la répartit en mode « wide NUMA ». Vérifiez le placement NUMA de vos serveurs virtuels avec esxtop (touche m pour la vue mémoire, colonne NHN pour le noeud NUMA home).

Lors de la migration à chaud (vMotion) d'un serveur virtuel entre serveurs physiques d'un cluster, le placement NUMA est recalculé sur l'hôte de destination. Dans un environnement de haute-disponibilité, vérifiez que les serveurs du cluster partagent la même topologie NUMA pour garantir des performances constantes après migration.

NUMA et bases de données : MySQL, PostgreSQL

Les bases de données sont les services les plus sensibles à la topologie NUMA sur un serveur dédié bi-processeur. Le buffer pool InnoDB de MySQL ou les shared buffers de PostgreSQL occupent souvent plusieurs dizaines de gigaoctets de RAM. Si cette mémoire est concentrée sur un seul noeud ou, pire, répartie aléatoirement entre les deux, les accès mémoire distants dégradent les performances de lecture.

MySQL et InnoDB

MySQL propose la variable innodb_numa_interleave (disponible depuis MySQL 5.7.9, activée par défaut depuis MySQL 8.4). Quand elle est activée, MySQL demande au noyau Linux de répartir les pages du buffer pool InnoDB en round-robin sur tous les noeuds NUMA (politique MPOL_INTERLEAVE). Une fois l'allocation terminée, la politique revient à MPOL_DEFAULT pour les allocations suivantes :

[mysqld]
innodb_numa_interleave = ON

L'entrelacement est recommandé pour les serveurs bi-processeur dont le buffer pool dépasse la mémoire d'un seul noeud. Il évite le scénario où un noeud sature sa mémoire locale et provoque du swap alors que l'autre noeud a encore de la RAM disponible.

PostgreSQL

PostgreSQL ne disposait pas nativement d'une option NUMA intégrée avant la version 18 (qui ajoute le support libnuma via l'option de compilation --with-libnuma et la fonction pg_numa_available()). Sur les versions antérieures, la pratique recommandée est de démarrer le processus avec numactl :

numactl --interleave=all /usr/lib/postgresql/16/bin/postgres -D /var/lib/postgresql/16/main

Ou via la directive ExecStart de l'unité systemd de PostgreSQL. Combinez l'entrelacement NUMA avec les huge pages (huge_pages = on dans postgresql.conf) pour réduire la surcharge de gestion des pages mémoire par le noyau et améliorer la localité d'accès aux shared buffers.

Répartir les services d'hébergement sur les noeuds NUMA

Un serveur dédié bi-processeur fait souvent office de plateforme d'hébergement complète, avec plusieurs services qui tournent en parallèle : serveur web (Apache, Nginx), serveur DNS pour la résolution des noms de domaine, serveur FTP pour les transferts de fichiers, sauvegardes automatisées et firewall applicatif. Chaque service a un profil mémoire différent, et le placement NUMA influe directement sur ses performances.

Le serveur web Apache ou Nginx bénéficie d'un épinglage sur un noeud quand il sert des milliers de connexions simultanées : ses caches et ses buffers d'envoi restent en mémoire locale. Si vous utilisez un panneau d'administration comme Plesk pour gérer vos sites, noms de domaine et boîtes mail, les processus Plesk gagnent à tourner sur le même noeud que le serveur web qu'il pilote.

Les tâches de backup et de sauvegardes sont typiquement gourmandes en bande passante mémoire (lectures séquentielles depuis le SSD vers un flux réseau ou un espace de stockage distant). Épinglez-les sur le noeud opposé à celui de vos services de production :

numactl --cpunodebind=1 --membind=1 rsync -az /var/backups/ backup-server:/data/

Pour planifier vos sauvegardes et préparer un plan de reprise sur un serveur dédié, consultez notre guide sauvegardes et haute-disponibilité.

Pour un firewall comme nftables, le placement NUMA n'a d'impact significatif que sur les serveurs à très haut débit réseau (10 Gbit/s). Dans ce cas, épinglez le traitement réseau sur le noeud dont le contrôleur réseau est physiquement le plus proche :

cat /sys/class/net/eth0/device/numa_node

NUMA dans un contexte de cluster et de haute-disponibilité

Quand vous déployez plusieurs serveurs dédiés bi-processeur en cluster (Proxmox Cluster, Kubernetes, Galera pour MySQL), l'optimisation NUMA se fait serveur par serveur. Chaque noeud du cluster est un serveur physique avec sa propre topologie NUMA : les réglages d'affinité ne se propagent pas automatiquement d'un serveur à l'autre.

Dans un environnement de haute-disponibilité avec migration automatique des serveurs virtuels (HA failover), vérifiez que les serveurs de destination ont la même topologie NUMA. Sur les serveurs dédiés Xeon Gold ElypseCloud, les machines d'une même gamme partagent une configuration matérielle identique (mêmes processeurs, mêmes bancs de RAM DDR4 ECC, même SSD), ce qui garantit un placement NUMA cohérent après migration.

La flexibilité d'un serveur dédié permet de contrôler chaque couche de l'environnement, du BIOS à l'ordonnanceur Linux. C'est un avantage décisif par rapport à un serveur VPS ou à un hébergement mutualisé, où l'hébergeur gère lui-même la répartition des ressources entre multiples serveurs virtuels. Pour comprendre les différences entre serveur dédié et VPS, consultez notre comparatif bare metal vs VPS.

Entrelacement mémoire : quand l'utiliser

L'entrelacement mémoire (memory interleaving) distribue les allocations en alternance sur tous les noeuds NUMA. C'est le contraire de l'épinglage : au lieu de forcer la localité, on accepte que chaque accès soit en moyenne à mi-chemin entre local et distant.

L'entrelacement est adapté quand :

• Un processus utilise plus de mémoire que ce qu'un seul noeud peut fournir ;
• Les accès mémoire sont répartis uniformément et sans motif prévisible (bases de données, caches) ;
• Vous ne pouvez pas prédire quel thread accédera à quelle page mémoire.

L'épinglage strict (--membind) est préférable quand :

• Un processus tient entièrement dans la mémoire d'un seul noeud ;
• Vous répartissez vos services entre les noeuds (un service par noeud) ;
• La latence mémoire est critique (trading haute fréquence, traitement temps réel).

Il est aussi possible de configurer l'entrelacement au niveau du BIOS (option Node Interleaving), mais cela masque la topologie NUMA au système d'exploitation : Linux ne voit plus qu'un seul noeud et ne peut plus optimiser le placement des processus. La recommandation est de laisser Node Interleaving désactivé dans le BIOS et de gérer l'entrelacement au niveau applicatif avec numactl ou les options de chaque service.

Récapitulatif des commandes NUMA

Sur les serveurs dédiés Xeon Gold ElypseCloud, les deux processeurs Xeon Gold 6230 forment deux noeuds NUMA avec 20 coeurs et 6 canaux mémoire DDR4 ECC chacun. Maîtriser cette topologie vous permet de tirer le meilleur parti des 40 coeurs, 80 threads et jusqu'à 512 Go de RAM disponibles sur ces serveurs physiques.

Pour comparer les deux gammes de serveurs dédiés (Xeon Gold 6230 et Xeon E5-2620 v4), consultez notre comparatif Xeon Gold vs Xeon E5. Si vous cherchez un serveur dédié à budget plus serré, la gamme Xeon E5 propose aussi une architecture bi-processeur à partir de 80 euros TTC par mois. Pour sécuriser votre serveur dédié dès la mise en service, suivez notre guide premiers réglages de sécurité. Pour une vue d'ensemble des caractéristiques du Xeon Gold 6230, consultez notre fiche technique détaillée.