EPYC : comment AMD a transformé les serveurs en vitrine

novembre 9, 2025 • février 3, 2026 • Lecture : 31 min • Views: 0

Cet article vous a aidé ?

Vous achetez un serveur en attendant qu’il se comporte comme un appareil fiable : latence prévisible, graphiques ennuyeux, pas de surprises à 2 h du matin.
Puis vous installez une machine AMD EPYC, lancez quelques dizaines de VM, ajoutez du NVMe, et soudain la visite du data center ressemble à celle d’un concessionnaire automobile :
« Regardez tous ces cœurs. Regardez les lanes. Regardez les canaux mémoire. »

Le problème, c’est que les vitrines sont optimisées pour l’effet « waouh ». La production est optimisée pour « rien d’étrange ne se produit ». EPYC peut faire les deux,
mais seulement si vous comprenez ce qu’il a changé dans la conception des serveurs — et où se trouvent les bords tranchants quand votre charge de travail rencontre NUMA, la topologie PCIe,
et une pile de stockage qui n’a jamais demandé autant de files d’attente parallèles.

Pourquoi EPYC a fait paraître les serveurs différents

EPYC n’a pas seulement offert plus de cœurs aux opérateurs. Il a changé l’apparence d’un serveur « équilibré ». Pendant longtemps, la conception des serveurs
était un ensemble de compromis acceptés par tous : pas assez de lanes PCIe, des canaux mémoire qui se remplissaient trop vite, et des CPU qui vous obligeaient
à des configurations dual-socket coûteuses juste pour obtenir de l’I/O.

EPYC est arrivé et a rendu le serveur mono-socket séduisant plutôt que l’option « budget ». Plus de lanes PCIe signifiaient que vous
pouviez attacher des NVMe sérieux sans jouer à Tetris. Plus de canaux mémoire signifiaient que vous pouviez alimenter ces cœurs sans être immédiatement à court
de bande passante. Et l’approche par chiplets a permis à AMD d’augmenter le nombre de cœurs sans nécessiter une puce monolithique de la taille de vos regrets.

L’effet vitrine est réel : vous pouvez désormais construire une machine qui paraît absurde sur le papier — des dizaines de cœurs, un mur de NVMe, et suffisamment
de bande passante mémoire pour faire transpirer les vieilles architectures. Mais l’effet vitrine a une ombre : si vous ignorez la topologie, vous créerez
des goulets d’étranglement qui n’apparaissent pas dans des benchmarks simples et ne se montrent que lorsque tout devient bruyant en même temps.

Faits et contexte qui expliquent la rupture

Voici des éléments historiques et contextuels concrets qui aident à expliquer pourquoi EPYC a été perçu comme un reset du marché, pas un simple lancement produit.
Ce ne sont pas des anecdotes. Ils se traduisent en décisions de conception que vous prendrez dans les racks et dans les feuilles de calcul d’achat.

2017 a été le point d’inflexion : EPYC « Naples » (1re gen) est arrivé et a forcé les acheteurs à reconsidérer la densité mono-socket comme un choix de premier plan.
Les chiplets sont devenus courants dans les serveurs : la conception multi-die d’EPYC a normalisé l’idée que la latence et la localité importent plus que la « pureté » d’un seul grand die.
Les canaux mémoire sont redevenus un critère d’achat : les configurations mémoire larges d’EPYC ont ramené la « bande passante mémoire par dollar » dans la salle de réunion.
Le nombre de lanes PCIe a cessé d’être une erreur d’arrondi : les plateformes avec beaucoup de lanes ont permis davantage de NVMe et de NICs sans CPU supplémentaires.
Rome (2e gen) a poussé les compteurs de cœurs : quand le nombre de cœurs augmente, les licences logicielles et le coût par cœur deviennent des risques opérationnels, pas seulement des lignes budgétaires.
Milan (3e gen) a amélioré latence et IPC : ce n’était pas seulement plus de cœurs ; le comportement mono-thread s’est amélioré au point d’importer pour les bases de données et les plans de contrôle.
Genoa (4e gen) a encore déplacé l’objectif I/O : DDR5 et PCIe Gen5 ont augmenté le plafond, mais ont aussi rendu les décisions de layout et de refroidissement plus conséquentes.
Les fournisseurs cloud l’ont validé en public : les grandes déploiements ont signalé « ce n’est pas de niche », ce qui compte quand vous investissez dans un écosystème de firmware, cartes et support.

Architecture utilisable (chiplets, NUMA, I/O)

Chiplets : la partie que tout le monde répète, et celle qui compte

« Chiplets » est souvent présenté comme un choix marketing. En production, c’est une histoire de topologie. Plusieurs dies de calcul (CCD) se connectent à un die I/O,
et vos threads, allocations mémoire et interruptions participent désormais à une leçon de géographie. Le CPU n’est plus un seul quartier ;
c’est une ville avec des ponts.

Cela impacte trois choses que vous ne pouvez pas ignorer :

Localité NUMA : la mémoire attachée à un nœud n’est pas aussi rapide depuis un autre. La pénalité varie selon la génération et la configuration, mais elle n’est jamais nulle.
Comportement du cache : un cache agrégé plus grand ne signifie pas que vos données chaudes sont proches de votre thread. « Proche » est désormais une propriété technique, pas une impression.
Jitter sous charge : lorsque le fabric est occupé — beaucoup d’I/O, beaucoup de cœurs, beaucoup d’interruptions — la latence en bout de file est ce que vous payez.

NUMA : vous ne pouvez pas « l’éteindre », vous pouvez seulement le mépriser

NUMA n’est pas un bug. C’est un contrat. Si vous placez mémoire et calcul sur le même nœud, vous obtenez une meilleure latence et bande passante. Si vous ne le faites pas, vous payez une taxe de performance.
Cette taxe est parfois suffisamment faible pour être ignorée. Parfois, c’est tout l’incident.

Les plateformes EPYC exposent couramment plusieurs nœuds NUMA par socket selon des réglages comme NPS (NUMA per socket) et la façon dont le noyau énumère l’I/O.
Vous pouvez tuner pour moins de domaines NUMA (ordonnancement plus simple, potentiellement plus de contention locale) ou plus de domaines (plus d’opportunités de localité,
plus de complexité).

Die I/O et abondance de lanes : le piège caché

EPYC a fait paraître l’I/O « résolu » parce que vous pouvez attacher beaucoup de périphériques. Mais « nombre de lanes » n’est pas synonyme d’« I/O sans contention ».
Switches, bifurcation, valeurs par défaut du firmware et routage des interruptions par le noyau peuvent toujours transformer une topologie glorieuse en un parking.

L’autre piège est psychologique : les équipes commencent à tout attacher parce qu’elles le peuvent. Plus de NVMe. Plus de NICs. Plus de HBA « au cas où ».
Puis la plateforme devient une expérience de bus partagé dont on est surpris que la QoS soit difficile.

Blague n°1 : Un serveur avec 128 lanes n’est pas « à l’épreuve du futur ». Il est « à l’épreuve de la tentation future », et la plupart d’entre nous échouent au test.

Virtualisation et consolidation : le bon, l’étrange, le réparable

EPYC est un moteur de consolidation. Si vous exploitez une ferme de VM avec beaucoup de VM « moyennes », vous pouvez augmenter la densité sans la taxe classique du dual-socket.
Mais la consolidation est l’endroit où l’effet vitrine mord : plus vous empaquetez, plus vous amplifiez les effets de l’ordonnanceur et de la mémoire que vous pouviez auparavant ignorer.

La densité de cœurs change les modes de défaillance

Quand vous passez de « quelques dizaines de threads » à « des centaines de threads exécutables », vos goulets d’étranglement changent :

Le CPU n’est pas la limite ; c’est la bande passante mémoire. Surtout pour l’analytique, la compression, le chiffrement et les piles de stockage avec beaucoup de copies.
Le traitement des interruptions redevient important. Une NIC rapide avec une mauvaise affinité IRQ peut ressembler à un problème CPU pendant que vos cœurs tournent sur des softirqs.
La contention sur les verrous devient visible. Certains logiciels montent jusqu’à 64 cœurs, puis chutent à 96 parce qu’un verrou global se transforme en tourniquet.

Licences et réalités « par cœur »

Votre équipe achat aimera les forts nombres de cœurs jusqu’au moment où elle ne les aimera plus. Certains logiciels d’entreprise facturent toujours par cœur, par socket,
par vCPU, ou avec des mathématiques de « core-factor » conçues pour vous faire sentir mal. EPYC facilite l’achat de plus de calcul que vous ne pouvez licencier raisonnablement.

Conseil opérationnel : traitez la licence comme une contrainte de performance. Si vous ne pouvez pas vous permettre d’utiliser tous les cœurs, ne faites pas semblant de les avoir.
Définissez des limites CPU réalistes, pinnez si nécessaire, et évitez de construire une architecture qui dépend de « nous licencierons plus tard ».

Quand le pinning est intelligent, et quand c’est du cosplay

Le pinning CPU et NUMA sont des outils puissants. Ce sont aussi une excellente façon de transformer votre plateforme de virtualisation en un tableau Excel maintenu à la main
qui casse à chaque ajout de NIC.

Le pinning vaut la peine quand :

vous avez des charges sensibles à la latence (systèmes de trading, plans de contrôle temps-réel-ish, certaines bases de données)
vous avez des hôtes dédiés pour un petit nombre de grosses VM
vous pouvez appliquer un placement cohérent et garder la dérive des hôtes sous contrôle

Le pinning est généralement une erreur quand :

l’environnement est très dynamique (autoscaling, évacuations fréquentes)
la charge est orientée débit et tolérante à la variance
l’équipe n’a pas d’observabilité pour les misses NUMA et les hotspots d’interruptions

Stockage et PCIe : lanes ≠ débit

L’histoire EPYC la plus courante en stockage est simple : « Nous avons attaché beaucoup de NVMe et attendu un scaling linéaire. » Parfois vous l’obtenez.
Souvent vous obtenez un plateau déroutant. Le plateau n’est pas une faute morale. C’est la combinaison de :

localité NUMA (vos interruptions NVMe sont traitées loin des threads applicatifs)
topologie PCIe (uplinks de switch, bifurcation, oversubscription)
profondeur des files et choix du ordonnanceur IO
comportement du système de fichiers et RAID/ZFS sous charges mixtes
interactions pile réseau/stockage (surtout dans Ceph, iSCSI, NVMe-oF)

Parallélisme NVMe : le CPU devient partie du chemin stockage

NVMe est rapide parce qu’il est parallèle. Cela signifie plus de files, plus d’interruptions, plus de temps CPU dans le noyau.
Sur EPYC, vous avez beaucoup de cœurs à allouer — mais vous devez toujours placer ce travail près du bon nœud NUMA,
et vous assurer de ne pas être limité par une seule file, une seule IRQ, ou un seul CPU traitant les softirqs.

Bande passante mémoire : le limiteur silencieux pour le stockage

Le stockage haute vitesse devient souvent « à quelle vitesse peut-on déplacer la mémoire ». Checksums, compression, chiffrement, réplication,
et même la simple copie peuvent saturer la bande passante mémoire bien avant que l’« utilisation CPU » ne paraisse inquiétante. Les canaux mémoire d’EPYC aident,
mais vous pouvez encore être à sec si vous utilisez un DIMM par canal, mélangez les vitesses, ou mal configurez les paramètres d’alimentation du BIOS.

Une citation fiabilité (idée paraphrasée)

Werner Vogels (idée paraphrasée) : « Tout échoue, tout le temps — concevez et exploitez comme si c’était la valeur par défaut. »

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les tâches que j’exécute réellement lorsqu’un hôte EPYC « devrait être plus rapide » mais ne l’est pas. Chacune inclut un extrait de sortie réaliste
et la décision que vous prenez à partir de celle-ci. Exécutez-les sur l’hôte, pas dans un conteneur, sauf indication contraire.

Tâche 1 : Confirmer le modèle CPU, les sockets et la disposition des cœurs

cr0x@server:~$ lscpu
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
CPU(s):                               128
Thread(s) per core:                   2
Core(s) per socket:                   64
Socket(s):                            1
NUMA node(s):                         4
Vendor ID:                            AuthenticAMD
Model name:                           AMD EPYC 9554 64-Core Processor
L3 cache:                             256 MiB
NUMA node0 CPU(s):                    0-31
NUMA node1 CPU(s):                    32-63
NUMA node2 CPU(s):                    64-95
NUMA node3 CPU(s):                    96-127

Ce que cela signifie : Vous avez un socket mais quatre nœuds NUMA. C’est une décision de topologie, pas juste un fait.

Décision : Si la charge est sensible à la latence, prévoyez un pinning NUMA-aware et un placement mémoire. Si c’est du généraliste, gardez NUMA visible
mais évitez le pinning complexe sauf si vous mesurez un gain.

Tâche 2 : Vérifier la distance NUMA (pénalité local vs remote)

cr0x@server:~$ numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0-31
node 0 size: 192000 MB
node 0 free: 121500 MB
node 1 cpus: 32-63
node 1 size: 192000 MB
node 1 free: 118200 MB
node 2 cpus: 64-95
node 2 size: 192000 MB
node 2 free: 119100 MB
node 3 cpus: 96-127
node 3 size: 192000 MB
node 3 free: 120900 MB
node distances:
node   0   1   2   3
  0:  10  12  12  12
  1:  12  10  12  12
  2:  12  12  10  12
  3:  12  12  12  10

Ce que cela signifie : L’accès mémoire distant coûte plus cher que local (distance 12 vs 10). Pas catastrophique, mais réel.

Décision : Pour les bases de données et les démons de stockage, alignez CPU/mémoire sur un nœud et essayez de garder les interruptions I/O locales.

Tâche 3 : Vérifier la vitesse mémoire et le peuplement

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Locator:|Size:|Speed:|Configured Memory Speed:'
Locator: DIMM_A1
Size: 64 GB
Speed: 4800 MT/s
Configured Memory Speed: 4800 MT/s
Locator: DIMM_B1
Size: 64 GB
Speed: 4800 MT/s
Configured Memory Speed: 3600 MT/s

Ce que cela signifie : Un DIMM est sous-cadencé (configuré à 3600). Cela peut tirer toute la sous-système mémoire vers le bas.

Décision : Corrigez les règles de peuplement (DIMM assortis, emplacements corrects). Ne benchmarkez pas tant que la mémoire ne fonctionne pas à la vitesse attendue.

Tâche 4 : Vérifier le comportement actuel de la fréquence CPU sous charge

cr0x@server:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,IPC,IRQ,POLL --interval 1 --num_iterations 3
Busy%  Bzy_MHz  IPC   IRQ   POLL
38.45  2850     1.35  6200  0
92.10  2975     1.02  18900 0
91.88  2400     0.98  20100 0

Ce que cela signifie : La fréquence chute à fort Busy% (politique thermique/puissance/firmware). L’IPC chute aussi, ce qui suggère des stalls mémoire ou de la contention.

Décision : Vérifiez le profil d’alimentation du BIOS, le refroidissement et le governor Linux. Si le débit compte, évitez des réglages d’alimentation conservateurs.

Tâche 5 : Inspecter le driver/gouverneur de fréquence CPU sous Linux

cr0x@server:~$ cpupower frequency-info
analyzing CPU 0:
  driver: amd-pstate-epp
  CPUs which run at the same hardware frequency: 0
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 3700 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 1580 MHz (asserted by call to hardware)

Ce que cela signifie : Vous êtes en powersave. Sur un serveur qui travaille réellement, c’est souvent accidentel.

Décision : Pour les hôtes critiques en performance, définissez performance et confirmez que les températures sont acceptables.

Tâche 6 : Confirmer la topologie PCIe et les largeurs de lien

cr0x@server:~$ lspci -tv
-[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 14xx
           +-01.1-[01]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller
           +-01.2-[02]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller
           +-03.0-[03]----00.0  Mellanox Technologies MT28908 Family [ConnectX-6]
           \-04.0-[04]----00.0  Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3

Ce que cela signifie : Les périphériques sont sur différents root ports — bon signe. Mais il faut quand même vérifier la vitesse/largeur négociée.

Décision : Si un NVMe a négocié x2 au lieu de x4 (ou Gen3 au lieu de Gen4/5), corrigez le câblage/backplane/bifurcation/BIOS avant de blâmer le logiciel.

Tâche 7 : Valider la vitesse/largeur PCIe négociée sur un périphérique

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap:|LnkSta:'
LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <16us
LnkSta: Speed 8GT/s (downgraded), Width x4

Ce que cela signifie : Capable de Gen4 (16GT/s) mais en fonctionnement Gen3 (8GT/s). Cela divise la bande passante par deux.

Décision : Vérifiez les paramètres PCIe du BIOS, le backplane, les retimers et le firmware. Ne « optimisez » pas le noyau pour compenser une dégradation physique.

Tâche 8 : Identifier la distribution des files NVMe et des interruptions

cr0x@server:~$ cat /proc/interrupts | egrep 'nvme|mlx5' | head
  95:   1200331   0   0   0   IR-PCI-MSI 524288-edge nvme0q0
  96:    903221   0   0   0   IR-PCI-MSI 524289-edge nvme0q1
  97:    910554   0   0   0   IR-PCI-MSI 524290-edge nvme0q2
 110:   3321100   0   0   0   IR-PCI-MSI 327680-edge mlx5_comp0

Ce que cela signifie : Toutes les interruptions atterrissent sur CPU0 (la première colonne) : un classique tueur de performance.

Décision : Activez/vérifiez irqbalance, ou pincez les IRQs vers le nœud NUMA local du périphérique. C’est souvent un gain de latence « gratuit ».

Tâche 9 : Vérifier la localité de la NIC et l’association au nœud NUMA

cr0x@server:~$ for dev in /sys/class/net/enp*; do echo -n "$(basename $dev) "; cat $dev/device/numa_node; done
enp65s0f0 2
enp65s0f1 2

Ce que cela signifie : La NIC est attachée au nœud NUMA 2. Si votre charge tourne sur le nœud 0 avec mémoire sur le nœud 0, vous payez la distance.

Décision : Pour le réseau haut débit (Ceph, NVMe-oF, réplication), placez les threads de la pile réseau près du nœud NUMA de la NIC.

Tâche 10 : Détecter la pression sur la bande passante mémoire via les compteurs perf

cr0x@server:~$ sudo perf stat -a -e cycles,instructions,cache-misses,dTLB-load-misses -I 1000 -- sleep 3
#           time             counts unit events
     1.000233062     5,210,332,110      cycles
     1.000233062     3,101,229,884      instructions
     1.000233062        92,110,553      cache-misses
     1.000233062         1,020,112      dTLB-load-misses
     2.000472981     5,401,223,019      cycles
     2.000472981     3,002,118,991      instructions
     2.000472981       120,004,221      cache-misses
     2.000472981         1,230,888      dTLB-load-misses

Ce que cela signifie : Des cache misses en hausse + une IPC en baisse indiquent une pression mémoire ou une mauvaise localité.

Décision : Examinez le placement NUMA, les huge pages, le comportement de l’allocateur et la localité des structures de données avant d’ajouter plus de cœurs.

Tâche 11 : Vérifier la saturation d’I/O disque et l’attente en file

cr0x@server:~$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.10    0.00    9.20    3.10    0.00   65.60

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz await  svctm  %util
nvme0n1        1200.0  800.0   420.0   310.0     620.0     9.80  6.20  0.35  99.8

Ce que cela signifie : Le périphérique est à ~100% d’utilisation et la profondeur de file est élevée (avgqu-sz). Await est de 6.2ms — élevé pour du NVMe sous cette charge.

Décision : Soit le périphérique est saturé (normal), soit vous avez un problème d’interruption/NUMA qui lui fait sembler saturé. Corrélez avec les interruptions et les softirq CPU.

Tâche 12 : Vérifier le coût CPU de la compression/checksum du système de fichiers ou ZFS (exemple : ZFS)

cr0x@server:~$ sudo zpool iostat -v 1 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
tank                        12.1T  10.7T   9800   6200   1.1G   820M
  mirror-0                  12.1T  10.7T   9800   6200   1.1G   820M
    nvme-SAMSUNG_MZQLB1T9-0     -      -   4900   3100   560M   410M
    nvme-SAMSUNG_MZQLB1T9-1     -      -   4900   3100   560M   410M

Ce que cela signifie : Ops et bande passante élevés ; si l’utilisation CPU est aussi élevée, les fonctionnalités ZFS (compression, checksums) peuvent être liées au CPU, pas au disque.

Décision : Si la latence est prioritaire, reconsidérez le niveau de compression, recordsize et les réglages sync — prudemment et en préservant l’intégrité des données.

Tâche 13 : Détecter une surcharge de softirq (congestion chemin réseau/stockage)

cr0x@server:~$ mpstat -P ALL 1 2 | head -n 20
Linux 6.5.0 (server)  01/10/2026  _x86_64_  (128 CPU)

01:01:10 PM  CPU   %usr  %nice  %sys %iowait  %irq  %soft  %steal  %idle
01:01:11 PM  all  18.20   0.00  12.30    2.10  0.90  15.40    0.00  51.10
01:01:11 PM    0   2.00   0.00   5.00    0.00  0.00  70.00    0.00  23.00

Ce que cela signifie : CPU0 est noyé sous les softirq. Cela correspond à « toutes les interruptions sur CPU0 ».

Décision : Corrigez l’affinité IRQ. Si vous utilisez DPDK ou du busy polling, validez la configuration et assurez-vous que c’est intentionnel.

Tâche 14 : Vérifier l’exposition de la topologie en virtualisation (exemple KVM/QEMU)

cr0x@server:~$ virsh capabilities | egrep -n 'topology|numa|cells' | head
115:      <topology sockets='1' dies='1' clusters='1' cores='64' threads='2'/>
132:      <cells num='4'>
133:        <cell id='0'>

Ce que cela signifie : L’hôte a 4 cellules NUMA. Vos VM peuvent être configurées pour correspondre (ou laissées décalées).

Décision : Pour les grosses VM, exposez NUMA à l’invité et alignez vCPU/mémoire. Pour les petites VM, gardez la simplicité sauf si vous pouvez mesurer un avantage.

Tâche 15 : Vérifier les preuves de capping thermique/puissance

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | egrep -i 'thrott|powercap|edac|mce' | tail
Jan 10 12:35:22 server kernel: amd_pstate: limiting max performance due to platform profile
Jan 10 12:41:07 server kernel: EDAC amd64: ECC error detected on CPU#0 Channel:1 DIMM:0

Ce que cela signifie : Le profil plateforme limite la performance, et vous avez aussi des erreurs ECC. Les deux peuvent se manifester comme une « lenteur aléatoire ».

Décision : Corrigez thermiques/profil d’alimentation d’abord ; remplacez ou réinsérez les DIMM problématiques immédiatement. Le tuning de performance sur une mémoire instable est de l’automutilation.

Feuille de diagnostic rapide

C’est le flux « j’ai 20 minutes avant que l’appel d’incident tourne en théâtre d’impro » . Il suppose que vous avez un hôte plus lent que prévu,
ou que la latence en bout de file explose sous charge.

Premier : séparer « saturation de ressource » de « topologie/pathologie »

Vérifier la distribution CPU et softirq : mpstat -P ALL 1 et cat /proc/interrupts. Si un CPU est saturé en softirq, arrêtez. Corrigez l’affinité IRQ.
Vérifier l’utilisation disque et la mise en file : iostat -x 1. Si %util ~100% avec await élevé, vous êtes soit réellement lié au périphérique soit vous avez un problème de localité/interruptions qui donne l’apparence d’une saturation périphérique.
Vérifier la pression mémoire : vmstat 1 (regardez si/so), et les compteurs perf si disponibles. Si vous swappez, tout le reste est bruit de fond.

Second : confirmer la négociation physique et la réalité firmware

Dégradations de lien PCIe : lspci -vv pour Speed/Width. Corrigez les problèmes Gen3-at-Gen4-capable avant de changer les knobs du noyau.
Sous-cadencement mémoire : dmidecode pour trouver les DIMM mal configurés. EPYC tournera, mais votre bande passante partira discrètement.
Throttling politique d’alimentation : cpupower frequency-info et les logs. Beaucoup de « régressions mystères » viennent de profils d’alimentation.

Troisième : aligner la localité pour le chemin critique

Cartographie NUMA : numactl --hardware, nœud NUMA de la NIC via sysfs, et localité des périphériques de stockage.
Pinnez seulement ce que vous devez : pour les grosses VM ou services dédiés, pinnez CPU et mémoire. Pour le reste, commencez par les corrections d’IRQ et d’alimentation.
Mesurez la latence de queue, pas les moyennes : les problèmes EPYC se cachent souvent dans le p99 pendant que le p50 semble correct.

Blague n°2 : Si votre première étape est « on va bidouiller des sysctl », vous ne diagnez pas — vous assaisonnez.

Trois mini-récits d’entreprise tirés du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une équipe plateforme a migré une flotte d’hôtes orientés stockage depuis d’anciens systèmes dual-socket vers de brillants serveurs EPYC mono-socket. Le plan semblait étanche :
moins de sockets, même RAM, plus de cœurs, plus de NVMe. Ils s’attendaient à une latence réduite et moins de consommation. La première semaine fut calme. Puis le job hebdomadaire a frappé :
compaction de sauvegarde plus indexation plus trafic client. Les graphiques de latence ont montré les crocs.

L’astreignant a supposé « les disques sont saturés ». Le %util NVMe était élevé, et les profondeurs de file semblaient moches. Ils ont ajouté plus de disques au prochain build
et étalé les données plus largement. Résultat : le même p99 de latence, maintenant avec plus de matériel.

Le vrai problème était la localité. La NIC et la moitié des NVMe étaient accrochés à une topologie PCIe qui poussait le noyau à router les interruptions sur CPU0.
CPU0 n’était pas « occupé » en espace utilisateur ; il était noyé sous les softirq et le traitement des interruptions. Les threads de stockage tournaient sur un autre nœud NUMA,
traversant constamment le fabric pour compléter l’I/O. Le système avait des cœurs disponibles — juste pas là où le travail atterrissait.

La correction fut ennuyeuse et chirurgicale : activer irqbalance comme baseline, puis surcharger l’affinité pour la NIC et les files NVMe afin de les garder locales au nœud NUMA du périphérique.
Ils ont aussi ajusté le placement des VM pour que les démons de stockage et leur mémoire restent proches de ce nœud.

La leçon clé n’était pas « irqbalance bon ». C’était : la mauvaise hypothèse était de traiter la saturation NVMe comme une propriété du périphérique plutôt que comme une propriété de bout en bout.
En territoire EPYC, le CPU et le fabric NUMA font partie de votre sous-système de stockage que ça vous plaise ou non.

Mini-récit 2 : L’optimisation qui a mal tourné

Une équipe compute exploitant un cluster de virtualisation chargé a décidé de tout pinner. Leur logique était raisonnable : NUMA existe, donc le pinning est bon,
donc pinner tout est mieux. Ils ont pinner les vCPU, pinner la mémoire, pinner les IRQs, et pinner quelques threads noyau pour la bonne mesure.

Le cluster semblait fantastique sous des charges stables. Puis la réalité est arrivée : des hôtes ont été évacués pour maintenance, des VM migrées, et l’orchestrateur
a commencé à remanier. Soudain, certains hôtes avaient des VM « parfaitement pinnées » posées sur les mauvais nœuds NUMA parce que les contraintes de placement originales
n’étaient pas préservées lors des migrations. Les performances sont devenues incohérentes : certaines VM tournaient très bien, d’autres ramait, et la différence dépendait de leur emplacement.

Le retour de bâton fut opérationnel. La stratégie de pinning nécessitait une discipline de placement stricte, mais l’équipe n’avait pas d’outillage pour la valider en continu.
Ils ont aussi créé de la fragmentation : des cœurs libres existaient, mais pas dans la bonne forme NUMA pour placer de nouvelles VM. L’ordonnanceur a commencé à rejeter des placements,
et les humains ont commencé à faire des déplacements manuels. C’est là que l’on apprend à quel point un cluster peut rapidement devenir un artefact sur mesure.

Ils ont défait la plupart des réglages. Le pinning est resté pour un petit ensemble de VM à forte valeur et au cycle de vie prévisible. Pour le reste, ils ont repris des valeurs par défaut sensées :
huge pages quand approprié, irqbalance avec overrides ciblés, et une politique hôte empêchant la gestion d’alimentation de les saboter.

La leçon : une optimisation qui exige des opérations parfaites n’est pas une optimisation ; c’est un instrument de dette avec un taux variable.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise a déployé de nouveaux hôtes EPYC pour un cluster de stockage. Rien d’exotique : NVMe, NICs haute vitesse, Linux standard, monitoring standard.
La fenêtre de changement était serrée, donc ils ont gardé l’image OS identique entre générations et ont compté sur l’automatisation.

Un hôte a commencé à montrer des pics de latence intermittents après une semaine. Pas assez pour déclencher des alertes globales, mais suffisamment pour provoquer des retries applicatifs
et des plaintes clients. Le graphe ressemblait à du bruit aléatoire — la classique appât « c’est le réseau ».

La pratique qui a sauvé la mise était douloureusement ennuyeuse : ils avaient une routine qui examinait les logs noyau pour les erreurs matérielles corrigées dans le cadre de l’hygiène hebdomadaire,
pas seulement durant les incidents. L’opérateur a repéré des corrections ECC et quelques messages PCIe AER sur l’hôte affecté. Pas de panique, juste une direction claire :
matériel ou firmware, pas tuning applicatif.

Ils ont planifié une maintenance contrôlée, réinséré les DIMM, mis à jour le firmware, et remplacé le module suspect. Les pics ont disparu.
Sans cette hygiène, l’équipe aurait perdu des semaines à « tuner » l’affinité IRQ et les paramètres de stockage pendant que la machine corrompait silencieusement la confiance.

La leçon : l’astuce de performance la plus rentable est d’empêcher le matériel instable d’imiter un problème logiciel.

Erreurs courantes (symptômes → cause racine → correction)

EPYC ne crée pas de nouvelles erreurs. Il amplifie les erreurs existantes. En voici celles que je vois régulièrement, avec des corrections spécifiques.

1) Symptom : pics de latence p99 sous charge ; le CPU paraît « idle » globalement

Cause racine : interruptions/softirqs concentrés sur quelques CPU ; le chemin critique est lié au CPU en espace noyau.
Correction : vérifiez /proc/interrupts ; activez irqbalance ; pincez les IRQs NIC/NVMe vers des CPU NUMA locaux ; vérifiez RPS/XPS si pertinent.

2) Symptom : plateau de débit NVMe bien en dessous des attentes

Cause racine : lien PCIe négocié à une vitesse inférieure (Gen3 vs Gen4/5) ou largeur réduite ; retimers/backplane/BIOS en défaut.
Correction : lspci -vv LnkSta ; corrigez les réglages BIOS ; mettez à jour le firmware ; validez le câblage/backplane ; retestez avant de tuner le logiciel.

3) Symptom : la base de données est plus lente après une montée en cœurs

Cause racine : saturation de la bande passante mémoire, accès mémoire NUMA distant, ou mur de contention sur les verrous.
Correction : alignez le process DB CPU/mémoire avec le nœud NUMA ; augmentez la localité ; envisagez moins de threads ; validez la vitesse/population mémoire.

4) Symptom : le cluster de virtualisation a des hôtes « bons » et « mauvais » aléatoires

Cause racine : réglages BIOS incohérents (mode NPS, profil d’alimentation), drivers/governors noyau incohérents, ou dérive de firmware.
Correction : standardisez BIOS/firmware ; appliquez dans le provisioning ; auditez avec lscpu, cpupower et inventaire DMI.

5) Symptom : l’utilisation CPU du stockage explose après activation de la compression/chiffrement

Cause racine : le CPU devient le goulet du stockage ; la bande passante mémoire et le comportement du cache dominent ; le coût par cœur évolue mal.
Correction : mesurez avec perf/turbostat ; ajustez le niveau de compression ; assurez la distribution des IRQ ; déplacez les démons lourds vers des nœuds locaux ; envisagez l’offload seulement si c’est réel.

6) Symptom : « Nous avons pinné les vCPU et ça s’est aggravé »

Cause racine : pinning sans aligner mémoire et localité I/O ; ou dérive opérationnelle rendant le pinning incohérent après migration.
Correction : appliquez le pinning comme une politique complète (CPU + mémoire + localité périphérique) pour un petit sous-ensemble ; sinon supprimez le pinning et corrigez d’abord IRQ/power.

7) Symptom : micro-stalls fréquents, difficiles à reproduire

Cause racine : erreurs ECC corrigées, retries PCIe AER, ou événements de capping thermique/puissance.
Correction : inspectez journalctl -k pour EDAC/AER ; traitez le matériel ; ne « tunez pas autour » des avertissements de fiabilité.

Listes de contrôle / plan pas à pas

Pas à pas : mettre un nouvel hôte EPYC en production sans drame

Standardiser les réglages BIOS : profil d’alimentation, mode NPS, politique SMT, paramètres génération PCIe. Documentez la position choisie et pourquoi.
Valider le peuplement mémoire : emplacements corrects, DIMM assortis, vitesse configurée attendue. Corrigez un sous-cadencement immédiatement.
Vérifier la négociation PCIe : contrôlez tous les NVMe et NICs pour la vitesse/largeur attendue ; assurez-vous qu’il n’y a pas de dégradations silencieuses.
Standardiser le comportement des fréquences CPU : confirmez governor/driver ; lancez un court test de charge et vérifiez que les fréquences ne s’effondrent pas de façon inattendue.
Confirmer la forme NUMA : enregistrez les sorties lscpu et numactl --hardware ; stockez-les avec l’inventaire hôte.
Définir la politique d’interruptions : activez irqbalance en baseline, puis ajoutez des overrides d’affinité ciblés pour les hotspots connus (NICs, NVMe) si vous avez des preuves.
Exécuter un smoke test stockage : lecture/écriture aléatoire avec profondeurs de file réalistes ; enregistrez p50/p95/p99 latence, pas seulement le débit.
Exécuter un smoke test réseau : validez le line rate, le coût CPU, et la distribution des IRQ ; assurez-vous qu’aucun cœur unique n’est saturé en softirq.
Établir une veille « santé matérielle » : logs EDAC, MCE, AER suivis. Traitez les erreurs corrigées comme des indicateurs avancés.
Puis seulement tuner les paramètres de charge : nombre de threads, pinning, huge pages, paramètres système de fichiers, etc. — basés sur des mesures.

Checklist : choisir entre EPYC mono-socket et dual-socket

Choisir mono-socket si vous avez besoin de beaucoup d’I/O, de mémoire modérée, et voulez une licence plus simple et une complexité de domaine de panne réduite.
Choisir dual-socket si vous avez véritablement besoin de capacité mémoire ou de bande passante au-delà de ce qu’un socket fournit, ou si votre workload exige plus d’endpoints PCIe sans switches.
Éviter dual-socket « juste parce que ». Cela double la complexité NUMA et augmente le rayon d’impact des pénalités mémoire distantes.

Checklist : quoi mesurer avant de blâmer EPYC

Vitesse/largeur négociée PCIe
vitesse mémoire configurée et population des canaux
distribution des IRQs sur les CPU
temps softirq et hotspots par cœur
placement NUMA du process et de sa mémoire
governor d’alimentation et preuves de throttling
latence en queue (p99) sous charge mixte

FAQ

1) EPYC est-il « meilleur » qu’Intel pour les serveurs ?

Cela dépend de ce que « meilleur » signifie. EPYC a été particulièrement fort quand vous avez besoin d’une forte densité de cœurs, beaucoup de PCIe, et une bonne
bande passante mémoire par dollar. Mais « meilleur » en production inclut aussi la maturité du firmware, la stabilité de la plateforme, et la façon dont votre logiciel
se comporte avec NUMA et un haut parallélisme.

2) Pourquoi mon EPYC mono-socket affiche-t-il plusieurs nœuds NUMA ?

Parce que la plateforme peut être configurée comme plusieurs domaines NUMA par socket (modes NPS), et la topologie chiplet/I/O expose des frontières de localité.
Traitez-les comme réelles : latence mémoire et localité I/O peuvent différer par nœud même sur un socket unique.

3) Dois-je activer SMT (équivalent hyperthreading) sur EPYC ?

En général oui pour les charges orientées débit, les environnements VM mixtes et les services généraux. Pour des scénarios stricts de latence ou des voisins bruyants, testez les deux.
SMT peut améliorer l’utilisation mais augmenter la latence en queue quand la contention est élevée.

4) Pourquoi mon NVMe tourne-t-il en Gen3 alors qu’il supporte Gen4/Gen5 ?

Causes courantes : génération forcée dans le BIOS, limitations du backplane/retimer, périphériques mixtes qui négocient vers le bas, problèmes d’intégrité du signal, ou firmware obsolète.
Confirmez avec lspci -vv et corrigez la couche physique/firmware avant de tuner Linux.

5) Dois-je pinner manuellement les IRQs ou irqbalance suffit-il ?

Commencez par irqbalance. Si vous voyez encore des hotspots (un CPU saturé en softirq) ou si vous avez besoin d’une latence cohérente, pincez les IRQs NIC/NVMe
vers des CPU locaux au nœud NUMA du périphérique. Le pinning manuel sans mesure tend à devenir une tradition immuable.

6) Quelle est la manière la plus rapide de dire si je suis lié par la bande passante mémoire ?

Cherchez une IPC basse sous charge (turbostat), des cache misses en hausse (perf stat), et un scaling qui cesse de s’améliorer avec plus de threads.
Vérifiez aussi que la mémoire n’est pas sous-cadencée et que les canaux sont correctement peuplés.

7) Un nombre de cœurs plus élevé est-il toujours meilleur pour les nœuds de stockage ?

Non. Les nœuds de stockage peuvent être limités par la bande passante mémoire, la gestion des interruptions et l’efficacité de la pile réseau. Plus de cœurs aident seulement si
le chemin critique se parallélise et si la localité est respectée. Sinon vous obtenez juste plus de cœurs à regarder un seul cœur faire le travail.

8) Dois-je configurer plus de nœuds NUMA par socket (NPS) pour la performance ?

Parfois. Plus de nœuds NUMA peuvent améliorer la localité si votre ordonnanceur et le placement applicatif sont NUMA-aware, surtout pour les charges I/O-intensives.
Mais cela augmente aussi la complexité opérationnelle. Si vous n’avez pas de discipline de placement, moins de nœuds NUMA peut être plus stable.

9) Quelle est la pire habitude de « tuning EPYC » ?

Traiter la topologie comme optionnelle. Si vous ignorez la distribution des IRQ, le placement mémoire et la négociation PCIe, vous passerez des semaines à « tuner » des sysctls et des nombres de threads
alors que le vrai goulet se tient à la vue de tous.

Prochaines étapes qui ne vous feront pas honte

EPYC a transformé les serveurs en vitrine en remettant la fiche technique au premier plan : cœurs, lanes, canaux et cache. C’est le titre.
La réalité opérationnelle est que la topologie redevient importante aussi, et la topologie punit la pensée approximative.

Étapes pratiques :

Inventoriez la topologie sur chaque hôte : forme CPU/NUMA, nœuds NUMA des NIC et NVMe, vitesses PCIe négociées. Stockez cela dans votre CMDB ou métadonnées de provisioning.
Standardisez BIOS et politique d’alimentation sur la flotte. Des profils incohérents créent des « hôtes hantés » qui gaspillent le temps SRE.
Basez une ligne de référence IRQ et softirq sous charge représentative. Si un CPU est la décharge du noyau, corrigez cela d’abord.
Mesurez p99 avant et après chaque changement. Si vous ne suivez que les moyennes, vous déclarerez victoire tandis que les utilisateurs continuent à relancer des requêtes.
Utilisez le pinning de façon chirurgicale : réservez-le aux charges qui le méritent et aux environnements capables de le maintenir.

L’objectif n’est pas de rendre vos serveurs EPYC impressionnants. Ils le sont déjà. L’objectif est de les rendre ennuyeux — et de les garder ennuyeux quand la charge devient méchante.