Le retour de Ryzen : pourquoi ça a paru soudain (alors que ce n’était pas le cas)

décembre 3, 2025 • février 3, 2026 • Lecture : 29 min • Views: 0

Cet article vous a aidé ?

Un trimestre, on vous dit « achetez Intel, c’est plus sûr ». Le trimestre suivant, votre DAF demande pourquoi la flotte du concurrent coûte moins cher, chauffe moins et parvient d’une manière ou d’une autre à terminer les tâches plus vite. Pendant ce temps, votre rotation d’astreinte découvre une nouvelle forme de douleur : pas l’incident dramatique, mais la régression de performance silencieuse et chronique qui n’arrive que sur certains hôtes.

L’essor de Ryzen a donné l’impression d’un retournement soudain parce que l’industrie voit les lancements produits, pas les années d’ingénierie, de chorégraphie de fabrication et de discipline opérationnelle derrière. Si vous gérez des systèmes de production, l’histoire de Ryzen est moins un « outsider qui gagne » qu’un « pari architectural qui paye, puis les équipes ops doivent réapprendre leurs réflexes ».

Pourquoi Ryzen a paru soudain

Le monde ne s’est pas réveillé un matin avec une AMD subitement compétente. Ce qui s’est passé est plus ennuyeux — et donc plus puissant. AMD a exécuté un plan pluriannuel couvrant l’architecture, les partenariats de technologie de fabrication, la stabilité de la plateforme et la segmentation produit. Le retour sur investissement est arrivé d’une façon qui ressemblait à un précipice parce que le marché était resté sur un plateau pendant un moment.

Si vous achetiez des CPU avant l’ère Ryzen, vous optimisiez essentiellement pour la prévisibilité : comportement de plateforme constant, flags du compilateur prévisibles, réglages BIOS fournis par le vendeur, et « les bizarreries qu’on connaît déjà ». Puis Zen est arrivé et a offert une proposition de valeur différente : beaucoup de cœurs, un IPC compétitif et une performance par euro qui a fait sourire les équipes d’achat comme si elles avaient trouvé une erreur de facturation.

C’est le ressenti « soudain » : un espace de décision auparavant conservateur s’est inversé. Pas parce que la physique a changé, mais parce que les compromis ont bougé. Et parce que le rythme d’Intel à l’époque a laissé un large objectif à AMD. Quand un acteur ralentit, l’autre n’a pas besoin d’être parfait, il lui suffit de livrer des pièces compétentes sans relâche.

Voici la vérité opérationnelle : le retour de Ryzen a aussi été le retour de la complexité optionnelle. Vous obtenez plus de boutons — topologies NUMA, comportement de la topologie mémoire, caractéristiques de l’interconnexion — en plus de la soupe habituelle de paramètres BIOS et de noyau. Le gain de performance était réel, mais le risque de se faire mal l’était aussi.

Enseignement décisif : Ryzen n’était pas « un nouveau CPU ». C’était un nouvel ensemble de contraintes. Traitez-le comme l’adoption d’un nouveau backend de stockage : mesurez, caractérisez, standardisez, puis scalez.

Ce qui a réellement changé sous le capot (et pourquoi ça importait)

Zen a été un rétablissement, pas une itération

Zen n’était pas « on va modifier Bulldozer ». C’était AMD qui reconstruisait son approche cœur : IPC plus élevé, meilleure prédiction de branchement, hiérarchie de caches améliorée et un cœur moderne capable de gagner sur le travail par thread et d’évoluer sur de nombreux threads. L’objectif n’était pas seulement de battre un benchmark ; c’était de construire une plateforme pouvant ancrer les Ryzen grand public et les EPYC serveurs sans être un projet de foire scientifique d’ingénierie.

D’un point de vue SRE, Zen a rendu autre chose possible : une montée en charge de performance prévisible. Pas parfaite — rien ne l’est — mais suffisante pour que la planification de capacité puisse à nouveau utiliser « cœurs × fréquence × profil de charge » sans rire nerveusement.

Les chiplets ont changé l’économie, puis la flotte

L’approche chiplet d’AMD est une décision qui paraît évidente après qu’on l’ait vue fonctionner. Séparer les dies de calcul des dies IO. Fabriquer les dies compute, denses et chauds, sur un nœud de procédé de pointe. Mettre l’IO et les contrôleurs mémoire sur un nœud plus mature. Le rendement s’améliore, le binning produit se diversifie, et l’entreprise peut livrer plus de SKU sans tout parier sur une puce monolithique.

En pratique, cela a fait deux choses :

Amélioration de l’approvisionnement et du prix/performance : de meilleurs rendements et un binning flexible se traduisent par « plus de cœurs à un prix donné ».
Création de réalités topologiques : la distance entre un cœur et son contrôleur mémoire, ou entre des cœurs dans différents chiplets, compte. La latence n’est plus une erreur d’arrondi.

C’est pourquoi Ryzen (et surtout EPYC) peut être à la fois un rêve et un piège. Si votre charge est orientée débit, vous gagnez beaucoup. Si vous êtes sensible à la latence et négligent la localité mémoire, vous pouvez perdre face à un CPU « plus lent » parce que vous avez accidentellement construit une loterie de mémoire distante.

Infinity Fabric : l’interconnexion que vous ignorez jusqu’à ce qu’elle vous facture

Infinity Fabric d’AMD est l’autoroute interne qui relie les chiplets et le die IO. Ce n’est pas que du marketing ; c’est une contrainte pratique. La fréquence du fabric et les réglages mémoire interagissent. Les paramètres BIOS par défaut sont souvent « sûrs », ce qui, en termes de performance, signifie « correct pour le desktop moyen, sous-optimal pour votre base de données de production ».

Que faire : standardisez les versions BIOS et les profils mémoire sur toute la flotte, et traitez les réglages liés au fabric comme une partie de la plateforme, pas comme de la « trivia d’optimisation ».

L’écosystème de la plateforme a mûri (silencieusement)

Quand on dit « Ryzen s’est amélioré », on veut souvent dire « drivers, BIOS, microcode, ordonnancement du noyau et firmware ont cessé d’être épicés ». Les premières générations Zen ont connu une vraie maturation de la plateforme au fil du temps. Cette maturation est invisible pour les consommateurs qui changent d’ordinateur tous les quelques années, mais douloureusement visible pour les SRE qui gèrent 400 nœuds identiques et ont besoin qu’ils se comportent de manière identique.

Un des gains moins glamours : les ordonnanceurs Linux et le comportement du NUMA balancing se sont améliorés pour la topologie d’AMD. Ce n’est pas un titre, mais c’est une raison pour laquelle un déploiement Ryzen/EPYC de 2023 semble plus fluide qu’un déploiement de 2017.

Opinion : si vous voulez que le succès de Ryzen paraisse « soudain » et sans effort, vous devez faire le travail non-soudain : discipline firmware, discipline version noyau et benchmarks reproductibles. Sinon vous accuserez le CPU de votre propre inconsistance.

Faits et contexte qui rendent la chronologie compréhensible

Ce ne sont pas des trivia. Ce sont les points « ah, maintenant je comprends » qui expliquent pourquoi l’essor de Ryzen paraît abrupt aux yeux des non-initiés.

Zen (2017) a été le premier véritable design de cœur compétitif d’AMD depuis des années et a réinitialisé les attentes d’IPC après l’ère Bulldozer/Piledriver.
La première génération d’EPYC (Naples, 2017) a mis les nombres de cœurs sur la table d’une manière qui a forcé les acheteurs de serveurs à reconsidérer « Intel par défaut ».
Le design chiplet a évolué plus vite que les dies monolithiques parce que les rendements et le binning facilitent la livraison cohérente de pièces à nombre élevé de cœurs.
Infinity Fabric a lié le comportement mémoire et interconnexion, rendant la configuration mémoire plus pertinente pour la performance CPU que ce dont de nombreuses équipes avaient l’habitude.
Zen 2 (2019) a déplacé le compute vers un nœud plus petit tout en utilisant un die IO séparé, améliorant l’efficacité et souvent le ratio performance/watt dans des flottes réelles.
Zen 3 (2020) a amélioré les relations cœur-cache et réduit les pénalités de communication inter-cœurs, ce qui a aidé les charges sensibles à la latence et mixtes.
Les atténuations de sécurité sont arrivées de manière inégale entre vendeurs et générations ; des « régressions » de performance étaient parfois plus liées aux atténuations qu’au silicium.
Les fournisseurs cloud ont validé AMD à grande échelle, ce qui a changé la perception du risque en entreprise : « s’ils l’exécutent, nous pouvons l’exécuter ».
Les outils et l’ordonnancement noyau ont rattrapé leur retard : l’écosystème Linux a appris de nouveaux schémas de topologie et amélioré les valeurs par défaut.

L’angle SRE : la performance est une caractéristique de fiabilité

En production, la performance n’est pas un luxe. C’est la marge qui vous évite d’être appelé à 3h du matin. Quand la marge CPU diminue, tout le reste paraît pire : latence des requêtes, profondeur des files d’attente, pauses GC, retard de réplication, arriérés de compactage, négociations TLS, voire des « pertes de paquets mystérieuses » dues à des softirqs surchargés.

Le retour de Ryzen a compté parce qu’il a redéfini ce que signifiait « marge raisonnable par euro ». Cela change les décisions d’architecture. Cela change le nombre de réplicas que vous pouvez vous permettre. Cela change le degré d’agressivité possible pour le chiffrement, la compression et l’observabilité.

Mais cela a aussi changé les modes de défaillance. Les nombres élevés de cœurs et les designs multi-chiplets amplifient des problèmes que vous pouviez auparavant ignorer :

Le NUMA redevient important : l’accès mémoire distant devient une taxe mesurable.
Le comportement de l’ordonnanceur compte : le placement des threads peut faire la différence entre un p99 stable et des oscillations chroniques.
La vitesse et les timings mémoire comptent : « ça boot » n’est pas un plan de performance.

Une citation qui devrait figurer sur le mur de chaque équipe ops, parce qu’elle est impolie et juste :

« Tout échoue, tout le temps. » — Werner Vogels

Ryzen n’a pas changé cela. Il a juste changé où vous ressentirez la défaillance en premier : dans les hypothèses héritées de la plateforme précédente.

Blague #1 : Le CPU n’était pas « plus lent après la mise à jour ». Votre monitoring venait juste de raconter la vérité avec une résolution plus fine.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (NUMA traité comme une pensée secondaire)

La société A a migré une couche d’API sensible à la latence depuis d’anciens serveurs bi-socket vers des hôtes AMD neufs avec beaucoup de cœurs. La migration était « simple » : construire une nouvelle image, exécuter la même version de Kubernetes, rediriger le trafic progressivement. Les tableaux de bord semblaient corrects — jusqu’à ce que ce ne le soient plus. Le p95 était OK, le p99 commençait à vaciller, et une fois par heure le taux d’erreur bondissait comme un battement de cœur.

L’ingénieur d’astreinte a poursuivi les suspects habituels : retransmissions réseau, voisins bruyants, IO disque, garbage collection. Rien d’évident. L’utilisation CPU n’a jamais dépassé 55 %, ce qui rendait l’incident d’autant plus frustrant. Les utilisateurs subissaient des timeouts tandis que les CPU « se reposaient ».

La cause racine était une hypothèse erronée : « un grand CPU = une grande piscine ». L’application utilisait un modèle thread-par-cœur et un gros cache en mémoire. Kubernetes répartissait les pods et les threads à travers les nœuds NUMA, et les allocations mémoire atterrissaient là où l’allocateur avait de la chance. Le résultat : des pics d’accès mémoire distante. Pas constants, mais corrélés au churn de cache et à des tâches de fond périodiques. Du classique jitter p99.

La correction n’a pas été héroïque. Elle a été ennuyeuse : pinner les pods aux nœuds NUMA, utiliser des politiques d’affinité CPU et mémoire, et valider avec un microbenchmark de latence simple sous charge. Ils ont aussi standardisé les réglages BIOS et désactivé quelques fonctions « d’économie d’énergie » excellentes pour les desktops mais médiocres pour la latence tail.

Enseignement décisif : si vous supposez que « NUMA ne compte pas », Ryzen finira par vous envoyer une facture avec intérêts.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (sur-optimisation mémoire et fabric)

La société B exploitait un cluster d’analytique axé stockage. Ils ont lu que la vitesse mémoire et le tuning d’Infinity Fabric pouvaient débloquer de la performance. Alors ils ont fait ce que font toujours les ingénieurs excités : ils ont réglé agressivement et déployé vite.

Ils ont augmenté les fréquences mémoire, ajusté les timings, activé un profil BIOS « optimisé » et célébré les gains précoces sur les benchmarks. Puis la prod a commencé à voir des erreurs machine check sporadiques et des redémarrages rares. Pas assez pour reproduire à la demande. Juste assez pour empoisonner la confiance dans toute la flotte.

Le retour de bâton était simple : le tuning était stable sous des benchmarks synthétiques CPU mais marginal sous des charges mixtes soutenues avec forte pression mémoire et variation de température. Un sous-ensemble de DIMM passait aux réglages optimisés dans un labo froid et était instable dans une baie chaude pendant les heures de pointe. Les réglages du fabric et de la mémoire interagissaient avec des marges d’erreur, et l’ECC corrigeait la plupart des erreurs — jusqu’à ce qu’il n’y parvienne plus.

Ils sont revenus à un profil mémoire conservateur, ont requalifié les DIMM, et ont introduit une règle : pas d’optimisation BIOS sans burn-in incluant pression mémoire, IO et soak thermique. Les benchmarks ne sont pas la production. La production est rancunière.

Enseignement décisif : « Stable dans un benchmark » n’est pas « stable en flotte ». Traitez le tuning BIOS comme un déploiement de code : déploiement progressif, canary, plan de rollback.

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

La société C avait une flotte mixte : Intel, AMD, plusieurs fournisseurs de cartes mères, plusieurs versions BIOS. Très tôt, ils ont décidé que c’était inacceptable. Ils ont créé une base plateforme : une courte liste de versions BIOS approuvées, de packages microcode, de versions noyau et un petit ensemble de paramètres power/perf. Ils maintenaient aussi une « nomenclature matériel connue bonne » pour les DIMM et les NIC.

Les gens se sont plaints. Les baselines semblent lentes. « Pourquoi ne puis-je pas juste mettre à jour le BIOS pour mon cluster ? » Parce que « mon cluster » devient « notre incident » quand un bug de coin rare frappe. Ils ont appliqué la baseline via des contrôles de provisioning et des audits périodiques.

Puis une mise à jour microcode est sortie et a changé les caractéristiques de performance pour un sous-ensemble de charges cryptographiques. D’autres équipes ont vu des régressions de latence et ont passé des semaines à bisecter des versions noyau. La société C a vu le changement rapidement parce qu’ils avaient des canaris alignés sur la baseline et une suite de benchmarks reproductible liée à chaque mise à jour firmware.

Ils ont mis le déploiement en pause, ajusté la planification de capacité, puis élargi le déploiement. Pas d’incident. Pas de drame. Juste un postmortem un peu suffisant : « Nous avons remarqué le problème avant qu’il ne remarque nos clients. »

Enseignement décisif : la discipline firmware est aussi ennuyeuse que les ceintures de sécurité, mais tout aussi vitale.

Tâches pratiques : commandes, sorties, décisions

Vous ne « sentez » pas la performance Ryzen. Vous la mesurez. Ci‑dessous des tâches pratiques à exécuter sur des hôtes Linux (bare metal ou VM, selon le cas). Chaque tâche indique ce que signifie la sortie et quelle décision prendre.

Task 1: Identify CPU model, sockets, and basic topology

cr0x@server:~$ lscpu
Architecture:             x86_64
CPU(s):                   64
Thread(s) per core:       2
Core(s) per socket:       32
Socket(s):                1
NUMA node(s):             2
Model name:               AMD EPYC 7543 32-Core Processor
L3 cache:                 256 MiB
NUMA node0 CPU(s):        0-31
NUMA node1 CPU(s):        32-63

Signification : Vous avez 2 nœuds NUMA même sur une seule socket. C’est normal pour beaucoup de designs EPYC. Votre charge peut traverser les nœuds sans s’en rendre compte.

Décision : Si vous tenez à la latence tail, prévoyez un pinning NUMA et une politique mémoire. Si vous êtes orienté débit, vous pouvez accepter les valeurs par défaut.

Task 2: Check kernel and microcode versions (baseline enforcement)

cr0x@server:~$ uname -r
6.1.0-18-amd64
cr0x@server:~$ dmesg | grep -i microcode | tail -n 3
[    0.412345] microcode: CPU0: patch_level=0x0a20120a
[    0.412346] microcode: CPU1: patch_level=0x0a20120a
[    0.412347] microcode: Microcode Update Driver: v2.2.

Signification : La version du noyau affecte l’ordonnancement et le comportement NUMA ; le microcode peut affecter la stabilité et la performance.

Décision : Si les hôtes diffèrent, cessez de comparer les benchmarks entre eux. Normalisez sur une baseline avant de faire de la « science ».

Task 3: Inspect NUMA distances (remote access penalty visibility)

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 0 size: 257751 MB
node 0 free: 241120 MB
node 1 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
node 1 size: 257751 MB
node 1 free: 239998 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

Signification : Distance 21 vs 10 implique un saut de latence important lorsque des threads sur le nœud 0 accèdent à de la mémoire allouée sur le nœud 1.

Décision : Si votre charge est sensible, appliquez la localité (pinning de processus, cpuset cgroup, politique mémoire NUMA).

Task 4: Verify current CPU frequency governor (avoid accidental power-save)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
schedutil

Signification : Le governor affecte la rapidité d’augmentation de fréquence des cœurs sous charge. Certains governors peuvent ajouter du jitter de latence.

Décision : Pour des services critiques en latence, envisagez des réglages de performance cohérents (souvent le governor « performance ») après validation des thermiques et budgets d’énergie.

Task 5: Check for throttling and thermal events (silent performance killers)

cr0x@server:~$ journalctl -k | grep -iE 'throttle|thermal|hwmon' | tail -n 5
Jan 10 09:12:41 server kernel: CPU0: Core temperature above threshold, cpu clock throttled
Jan 10 09:12:41 server kernel: CPU0: Package temperature/speed normal

Signification : Le throttling peut faire qu’un « CPU rapide » se comporte comme un CPU médiocre, surtout sous charge soutenue.

Décision : Réparez le refroidissement, le flux d’air et les limites d’alimentation avant de tuner le logiciel. Si vous ne pouvez pas le garder au frais, vous ne pouvez pas le garder rapide.

Task 6: Validate memory speed and channel population (fabric/memory reality check)

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Locator|Speed|Configured Memory Speed' | head -n 12
Locator: DIMM_A1
Speed: 3200 MT/s
Configured Memory Speed: 3200 MT/s
Locator: DIMM_B1
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Locator: DIMM_C1
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s

Signification : Les DIMM peuvent être capables de 3200 MT/s, mais la plateforme les fait tourner à 2933 MT/s (souvent à cause des règles de population ou des valeurs par défaut du BIOS).

Décision : Si la performance est limitée par la mémoire, corrigez la population DIMM et la configuration BIOS ; ne vous contentez pas d’« ajouter des nœuds ».

Task 7: Confirm ECC is enabled and check corrected error counts

cr0x@server:~$ sudo edac-util -v
edac-util: EDAC drivers are loaded.
mc0: 0 CE, 0 UE
mc1: 12 CE, 0 UE

Signification : Les erreurs corrigées (CE) ne sont pas gratuites ; elles indiquent une marge qui se dégrade. Les erreurs non corrigées (UE) sont l’alarme incendie.

Décision : Si les CE augmentent, planifiez le remplacement des DIMM et envisagez d’adoucir l’optimisation mémoire. N’attendez pas que les UE vous « apprennent » la leçon.

Task 8: Identify whether you’re CPU-bound or stalled on IO

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 241120  18244 981232    0    0     3    12  540 1020 12  3 84  1  0
 8  0      0 241100  18244 981240    0    0     0     0 1240 5900 58  8 33  1  0
 9  0      0 241090  18244 981260    0    0     0     4 1320 6100 61  9 28  2  0

Signification : Un r élevé avec peu d’idle (id) suggère une contention CPU. Un wa élevé suggère un attente IO. Un nombre élevé de commutations de contexte (cs) peut indiquer une pression de l’ordonnanceur.

Décision : Si vous êtes CPU-bound, investiguez le placement des threads, les hotspots et le comportement de fréquence. Si vous êtes IO-bound, cessez d’accuser le CPU et profilez stockage/réseau.

Task 9: Find per-core utilization and softirq pressure (network-heavy services)

cr0x@server:~$ mpstat -P ALL 1 3 | tail -n 8
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Average:      0    72.00    0.00   12.00    0.00    0.00    6.00    0.00    0.00    0.00   10.00
Average:      1     8.00    0.00    3.00    0.00    0.00   65.00    0.00    0.00    0.00   24.00
Average:     31     5.00    0.00    2.00    0.00    0.00    1.00    0.00    0.00    0.00   92.00

Signification : Le CPU1 est dominé par les softirq, souvent le traitement réseau. Un cœur chaud peut plafonner le débit alors que « le CPU global » a l’air correct.

Décision : Examinez l’affinité IRQ, les réglages RPS/XPS, le nombre de queues NIC, et vérifiez que vous n’avez pas accidentellement pinner tous les interrupts sur un seul nœud NUMA.

Task 10: Measure scheduler run queue latency and context switches with perf

cr0x@server:~$ sudo perf stat -e context-switches,cpu-migrations,cycles,instructions,cache-misses -a -- sleep 10
 Performance counter stats for 'system wide':

     18,240,112      context-switches
        420,331      cpu-migrations
  42,901,112,004      cycles
  61,221,990,113      instructions              #    1.43  insn per cycle
   1,220,991,220      cache-misses

      10.001234567 seconds time elapsed

Signification : Des migrations élevées peuvent indiquer que l’ordonnanceur déplace les threads entre cœurs/nœuds NUMA, nuisant à la localité du cache. L’IPC donne un signal de santé approximatif ; les cache-misses suggèrent une pression mémoire.

Décision : Si les migrations sont élevées et la latence instable, imposez une affinité ou examinez les limites et politiques cpus des conteneurs.

Task 11: Check C-state residency (latency jitter and wake-up costs)

cr0x@server:~$ sudo powertop --time=1 --html=/tmp/powertop.html >/dev/null 2>&1
cr0x@server:~$ ls -lh /tmp/powertop.html
-rw-r--r-- 1 root root 188K Jan 10 09:44 /tmp/powertop.html

Signification : Le rapport montre le temps passé par les CPU dans les C-states profonds. Le sommeil profond économise de l’énergie mais peut ajouter de la latence au réveil.

Décision : Pour des services à latence tail, envisagez de limiter les C-states profonds dans le BIOS ou via des paramètres noyau — après avoir mesuré l’impact sur la consommation et les thermiques.

Task 12: Validate transparent huge pages and memory fragmentation risk

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Signification : THP « always » peut aider certaines charges et en nuire à d’autres (pics de latence lors de la defrag/compaction). Ryzen n’est pas spécial ici, mais des nombres de cœurs plus élevés peuvent amplifier la contention de l’allocateur.

Décision : Pour les bases de données et services critiques en latence, testez madvise ou never plutôt que d’hériter des valeurs par défaut.

Task 13: Confirm NUMA balancing is doing what you think

cr0x@server:~$ cat /proc/sys/kernel/numa_balancing
1

Signification : Le NUMA balancing automatique peut améliorer la localité pour certaines charges, ou introduire des scans et du jitter pour d’autres.

Décision : Si vous observez des pics périodiques de latence et des migrations élevées, testez la désactivation sur un canari et comparez p99/p999.

Task 14: Check memory bandwidth and latency signals (quick-and-dirty)

cr0x@server:~$ grep -E 'MemTotal|MemFree|MemAvailable' /proc/meminfo
MemTotal:       528898032 kB
MemFree:        241120000 kB
MemAvailable:   410552000 kB

Signification : Ce n’est pas un test de bande passante, mais un contrôle de cohérence. Si MemAvailable est faible, le système est sous pression mémoire et peut effectuer du reclaim/compaction, ce qui peut imiter une « lenteur CPU ».

Décision : Si la pression mémoire est élevée, corrigez cela d’abord (taille du cache, placement des charges) avant d’accuser la génération CPU.

Task 15: Verify disk and filesystem aren’t the actual bottleneck (storage engineer’s reflex)

cr0x@server:~$ iostat -xz 1 3
Device            r/s     w/s   rKB/s   wKB/s  avgrq-sz  avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         12.00   90.00   384.0  9216.0     184.0      3.20   28.10    5.20   31.10   0.45  46.80

Signification : await et avgqu-sz suggèrent de l’enrôlement en file d’attente. Si le stockage fait la queue, votre CPU attend l’IO, il n’« est pas lent ».

Décision : Si le %util est élevé et que l’await augmente sous charge, faites le travail stockage : profondeurs de queue, ordonnanceur IO, options système de fichiers, ou santé NVMe.

Task 16: Check virtualization features and whether you’re inside a VM (don’t benchmark the wrong thing)

cr0x@server:~$ systemd-detect-virt
none
cr0x@server:~$ lscpu | grep -i hypervisor

Signification : Si vous êtes dans une VM, la topologie CPU et le comportement de fréquence peuvent être virtualisés et trompeurs.

Décision : Benchmarquez sur du bare metal ou assurez-vous que l’hyperviseur expose une topologie et un pinning cohérents ; sinon les résultats sont de la fiction performance.

Blague #2 : Faire des benchmarks dans une VM bruyante et appeler ça de la « science CPU » revient à chronométrer un marathon sur un tapis de course pendant que quelqu’un change l’inclinaison.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Ceci est le playbook « c’est lent, les clients râlent et vous avez 15 minutes ». L’objectif n’est pas l’élégance. L’objectif est de trouver rapidement le goulet dominant et de choisir l’action suivante.

First: classify the bottleneck (CPU vs memory vs IO vs scheduler)

Vérifier la saturation et l’attente CPU : vmstat 1 et mpstat. Si id est bas et r est élevé, vous êtes CPU-bound. Si wa est élevé, c’est généralement IO-bound. Si un cœur est saturé en softirq, c’est souvent réseau/affinité IRQ.
Vérifier l’enrôlement disque : iostat -xz 1. Un await élevé avec avgqu-sz croissant signifie que le stockage est en cause.
Vérifier la pression mémoire : grep MemAvailable /proc/meminfo et dmesg pour OOM/avertissements de reclaim. La pression mémoire se fait souvent passer pour une « lenteur CPU ».

Second: confirm topology and placement (NUMA + pinning)

Topologie : lscpu et numactl --hardware. Si vous avez plusieurs nœuds NUMA, supposez que la mémoire distante est possible.
Migrations : perf stat avec cpu-migrations. Des migrations élevées suggèrent une mauvaise affinité ou des contraintes cgroup qui causent des rebonds.
Placement des conteneurs : Validez cpuset et la politique mémoire si vous exécutez Kubernetes ou des slices systemd. N’improvisez pas — inspectez.

Third: check the “silent killers” (firmware, throttling, mitigations)

Throttling : logs noyau pour événements thermiques. Réparez le refroidissement et les limites d’alimentation avant de tuner.
Dérive firmware : versions noyau + microcode. Une flotte BIOS mixte rend la performance imprévisible.
Atténuations et paramètres noyau : Si une mise à jour récente a changé la performance, comparez paramètres de boot et baselines microcode. Ne désactivez pas les atténuations à la légère ; quantifiez l’impact et décidez avec la sécurité.

Règle : Ne touchez pas au tuning sans avoir mesuré. Ne mesurez pas ce que vous ne pouvez pas reproduire. Ne reproduisez pas sur un système que vous ne pouvez pas décrire.

Erreurs courantes : symptôme → cause racine → correction

C’est là que le côté « Ryzen a paru soudain » mord les équipes : elles appliquent l’ancien modèle mental sur la nouvelle plateforme.

1) Symptom: p99 latency jitter after migrating to Ryzen/EPYC

Cause racine : accès mémoire NUMA distant dû au placement de l’ordonnanceur et au comportement de l’allocateur à travers nœuds/chiplets.

Correction : Pinner les processus/pods par nœud NUMA ; utiliser des cpusets ; vérifier avec numastat et perf ; tuner ou désactiver le NUMA balancing automatique s’il ajoute du jitter.

2) Symptom: CPU usage is “low,” but throughput is capped

Cause racine : un seul cœur saturé sur softirq/gestion d’IRQ ; mauvaise configuration des queues NIC/affinité ; hotspot mono‑thread.

Correction : Inspecter mpstat pour une domination softirq ; répartir les IRQ sur plusieurs cœurs/nœuds NUMA ; augmenter les queues NIC ; corriger le hotspot ou paralléliser ce chemin critique.

3) Symptom: Benchmarks great, production flaky (rare reboots/MCE)

Cause racine : réglages mémoire/fabric sur-optimisés sans soak thermique ni validation sur charges mixtes.

Correction : Revenir à des profils JEDEC stables ; valider avec des stress tests longs ; surveiller les EDAC corrected errors ; remplacer les DIMM marginaux.

4) Symptom: “Same SKU,” different performance across hosts

Cause racine : dérive firmware (BIOS/microcode), population DIMM différente, limites d’alimentation différentes, ou différences thermiques.

Correction : Appliquer une baseline plateforme ; auditer les versions BIOS ; standardiser les DIMM et les courbes de ventilateur ; vérifier les réglages power/perf.

5) Symptom: CPU frequency doesn’t ramp, service feels sluggish under burst

Cause racine : governor conservateur, C-states profonds, ou politique d’alimentation orientée efficacité plutôt que latence.

Correction : Évaluer un changement de governor ; envisager de limiter les C-states profonds ; mesurer l’impact sur la latence tail avant/après.

6) Symptom: “More cores” didn’t reduce job runtime

Cause racine : goulot bande passante mémoire, contention de verrou, ou goulot IO. Les cœurs ne résolvent pas la sérialisation.

Correction : Profiler : mesurer cache misses, file d’exécution, attente IO ; sharder le travail ; réduire la contention de verrous ; améliorer la localité ; scaler le véritable goulot (canaux mémoire, NVMe, réseau).

7) Symptom: Database replication lag increases on new hosts

Cause racine : placement NUMA mixte, comportement THP, ou enroulement des IO selon des patterns différents.

Correction : Pinner les processus DB ; définir la politique THP adaptée à la DB ; tuner l’ordonnanceur IO et les profondeurs de queue ; vérifier avec iostat et les métriques DB.

Listes de vérification / plan pas à pas

Voici les étapes opérationnelles qui transforment « Ryzen a l’air génial sur le papier » en « Ryzen se comporte en production ». Elles sont volontairement dépourvues de romantisme.

Checklist 1: Pre-purchase and platform selection (don’t buy surprises)

Choisir 2–3 charges représentatives (API à latence, analytique batch, job lourd stockage).
Définir les critères de succès en termes production : p99, débit par watt, coût par unité de travail, impact sur le budget d’erreur.
Exiger une BOM matériel qui inclut le modèle exact de DIMM et le plan de population ; éviter les pièces « équivalentes » sauf tests.
Décider si votre charge se préoccupe du NUMA. Si oui, budgéter du temps d’ingénierie pour affinité et placement.
Confirmer que NIC et stockage s’alignent sur la topologie NUMA (par ex. NIC sur le même nœud que les cœurs les plus sollicités).

Checklist 2: Bring-up and baseline (make hosts comparable)

Définir une version BIOS approuvée et l’appliquer à chaque hôte avant le benchmarking.
Verrouiller une version noyau et un package microcode ; documenter comme un contrat d’API.
Enregistrer les sorties lscpu et numactl --hardware par classe matérielle.
Valider la vitesse mémoire et la santé ECC (dmidecode + edac).
Exécuter un burn-in incluant CPU, pression mémoire, IO et soak thermique ; conserver les logs.

Checklist 3: Deployment strategy (avoid the “fleet-wide mystery regression”)

Canary : déployer sur un petit pourcentage de trafic et le garder assez longtemps pour observer les patterns diurnes.
Comparer pommes avec pommes : même version de logiciel, même noyau, même BIOS, même politique power.
Surveiller p99/p999 et taux d’erreur, pas la latence moyenne. Les moyennes sont l’endroit où les incidents se cachent.
Valider l’affinité IRQ et CPU si gros usage réseau ; surveiller les cœurs chauds softirq.
Automatiser la détection de dérive pour BIOS/microcode/noyau ; traiter la dérive comme un précurseur d’incident.

Checklist 4: NUMA-aware configuration (if you care about tail latency)

Pinner les processus principaux du service à un nœud NUMA (ou un ensemble de cœurs) et garder la mémoire locale.
Co-localiser les interruptions les plus chaudes et les threads les plus chauds quand possible (même nœud).
Tester avec et sans NUMA balancing automatique sur des canaris ; choisir selon la stabilité p99.
Documenter la politique pour que les futurs ingénieurs ne « nettoient pas » tout pendant une refactorisation.

FAQ

1) Did Ryzen “suddenly” beat Intel?

Non. Ce fut une montée sur plusieurs générations : Zen a établi la compétitivité, Zen 2 a amélioré l’efficacité et l’évolutivité, Zen 3 a amélioré le comportement pour charges sensibles à la latence. La perception du marché a traîné derrière l’exécution.

2) Why do chiplets matter for real deployments?

Ils changent la dynamique coût/approvisionnement (meilleurs rendements) et les caractéristiques de performance (topologie et latence). Vous obtenez plus de cœurs par euro, mais vous devez respecter la localité.

3) Is Ryzen only good for multi-threaded workloads?

Il brille dans le travail orienté débit, mais les cœurs Zen modernes sont aussi performants par thread. La vraie question est de savoir si votre charge est limitée par la latence mémoire, la bande passante ou l’IO.

4) Why do my benchmarks disagree between identical-looking servers?

« Identiques en apparence » ne veut souvent pas dire identiques : versions BIOS, microcode, population DIMM, limites d’alimentation et thermiques diffèrent. Baselinez la plateforme avant de croire les résultats.

5) Should I disable security mitigations to get performance back?

Pas par défaut. Quantifiez l’impact, impliquez la sécurité et envisagez des atténuations ciblées uniquement avec un modèle de menace clair. Sinon vous optimiserez vers un incident évitable.

6) What’s the fastest way to tell if NUMA is hurting me?

Vérifiez lscpu / numactl --hardware pour plusieurs nœuds, puis cherchez des migrations élevées (perf stat) et du jitter p99 sous charge. Si le pinning améliore la latence tail, le NUMA faisait partie de la taxe.

7) Do BIOS “performance profiles” help?

Parfois. Ils peuvent aussi se retourner contre vous via thermiques, instabilité ou jitter dû à un boost agressif. Traitez le tuning BIOS comme un déploiement progressif avec burn-in et rollback.

8) Is EPYC just “Ryzen for servers”?

Ils partagent de l’ADN architectural, mais les pièces serveurs mettent l’accent sur les canaux mémoire, l’IO, les fonctionnalités de fiabilité et la validation plateforme. Les conséquences opérationnelles (NUMA, layout PCIe, discipline firmware) sont plus prononcées.

9) How should I capacity plan when moving to Ryzen/EPYC?

Commencez par caractériser la charge : CPU-bound vs memory-bound vs IO-bound. Ensuite benchmarkez sur une plateforme baseline et construisez des cibles de marge en utilisant le p99, pas les moyennes.

10) What’s the single most common ops mistake during migration?

Supposer que l’ordonnanceur « fera la bonne chose » pour la localité. Parfois il le fera. Souvent il ne le fera pas — surtout sous contraintes de conteneurs et charges mixtes.

Conclusion : prochaines étapes concrètes

L’essor de Ryzen a paru soudain parce que l’industrie regardait les annonces tandis qu’AMD peaufinait l’architecture, la stratégie de fabrication et la maturité de l’écosystème. Ensuite la courbe a franchi le seuil où les achats, les fournisseurs cloud et les gestionnaires de risque d’entreprise ont tous dit la même chose : « Très bien, on peut l’utiliser. » C’est là que ça a ressemblé à un succès du jour au lendemain.

Si vous gérez des systèmes de production, la morale n’est pas « achetez Ryzen ». La morale est : n’importez pas les hypothèses d’hier dans la topologie d’aujourd’hui.

Prochaines étapes pratiques

Baseliner votre plateforme : choisissez BIOS, microcode, versions noyau ; appliquez-les.
Exécuter la découverte de topologie sur chaque classe matérielle : capturez lscpu et numactl ; documentez la disposition NUMA pour les développeurs.
Construire une suite de benchmarks minimale : un test de latence, un test de débit, un test IO mixte ; exécutez‑les sur des canaris après chaque changement firmware/noyau.
Décidez si vous tenez à la latence tail : si oui, implémentez affinité et politiques NUMA ; si non, ne perdez pas de temps à micro-optimiser.
Surveillez les tueurs silencieux : throttling, erreurs ECC corrigées, cœurs IRQ chauds et dérive firmware.

Ryzen n’a pas gagné en étant magique. Il a gagné en étant conçu comme quelqu’un qui entendait expédier à grande échelle. Si vous l’opérez de la même manière — mesuré, standardisé et conscient de la topologie — vous obtiendrez vous aussi la performance « soudaine ». Sauf que ce ne sera pas soudain.