DDR4 vers DDR5 : ce qui rend vraiment votre système plus rapide (et ce qui ne le fait pas)

Ce qui a changé de DDR4 à DDR5 (et pourquoi c’est important)

Le titre marketing pour la DDR5 est « débit de données plus élevé ». Vrai. Mais le titre opérationnel est « modes de défaillance différents, réglages différents,
et façons différentes de gaspiller accidentellement ce que vous avez acheté ».

1) La DDR5 pousse davantage la bande passante ; la latence ne s’améliore pas magiquement

La bande passante augmente parce que le débit de transfert augmente et que le sous-système est conçu pour le soutenir davantage. Mais la latence bout en bout est une chaîne :
cœur → hiérarchie de caches → contrôleur mémoire → timings DRAM → chemin de retour. La DDR5 peut augmenter le débit brut tout en ayant une latence « première donnée »
similaire (ou parfois pire) comparée à une configuration DDR4 bien réglée, surtout si l’on compare une DDR5 bon marché aux timings lâches à une DDR4 serrée.

En termes de production : les charges en streaming (scan, ETL, analytique, compression, certains pipelines de données ML) ont tendance à apprécier la DDR5.
Les charges pointer-heavy, branchées, à petits accès aléatoires (certains patterns OLTP, chemins chauds key-value, métadonnées intensives) se soucient souvent plus de la latence et du comportement du cache.

2) Deux sous-canaux 32 bits par DIMM modifient le comportement de la concurrence

Les DIMM DDR5 sont effectivement divisés en deux sous-canaux indépendants de 32 bits (plus les bits ECC quand présents). L’objectif est une meilleure parallélisation au niveau des banques et
une utilisation plus efficace du bus pour les petites transactions. Cela peut réduire la pénalité des « bulles » et améliorer la bande passante effective sous des accès mixtes.

Opérationnellement : cela peut lisser le débit sous concurrence. Cela n’excuse pas un mauvais placement NUMA ou une surallocation de mémoire.

3) Gestion d’alimentation sur DIMM (PMIC) et comportement d’entraînement différent

La DDR5 déplace plus de gestion d’alimentation sur le DIMM via un PMIC. C’est un bon point d’ingénierie : meilleure alimentation aux hautes vitesses.
Cela signifie aussi que vous avez ajouté un composant supplémentaire qui peut influencer la thermique, la stabilité et la façon dont le firmware entraîne la mémoire.

Quand vous voyez « seulement stable à DDR5-4400 à moins qu’on augmente X », ce n’est rarement « Linux qui est bizarre ». C’est l’intégrité du signal, les marges d’entraînement, le firmware,
et parfois un choix de population DIMM que le routage de la carte n’aime pas.

4) La DDR5 change l’histoire de la fiabilité : options ECC, on-die ECC, et malentendus

La DDR5 introduit de l’on-die ECC dans beaucoup de puces, ce qui aide la DRAM à corriger certains problèmes au niveau cellule. Ce n’est pas la même chose que l’ECC bout en bout
au niveau système. Si vous avez besoin d’une détection/correction d’erreurs visible par le contrôleur mémoire (et journalisée), vous voulez toujours des DIMM ECC et une plateforme
qui les supporte.

Si vous exploitez des systèmes de production qui stockent de l’argent, des données médicales, ou des décisions prises sous privation de sommeil, vous savez déjà quoi acheter : ECC, validé,
et ennuyeux.

5) Capacités plus élevées et plus de rangs comptent plus que vous ne le pensez

La DDR5 a facilité la fabrication de DIMM à plus haute capacité et de configurations mémoire plus denses. C’est souvent là que se cachent les histoires « la DDR5 a rendu mon système plus rapide » :
pas la vitesse, la capacité. Si la DDR5 vous permet de garder votre working set en RAM au lieu d’échanger ou de thrash le cache de pages, vous verrez une amélioration spectaculaire.
Ce n’est pas une histoire de bande passante. C’est une histoire « arrêtez de faire des IO pour rien ».

Ce qui s’accélère avec la DDR5

Charges limitées par la bande passante mémoire : le gain évident, mais vérifiez

Si vous saturez la bande passante mémoire, la DDR5 peut aider. Vous le verrez sur :
grands scans séquentiels, requêtes analytiques qui streament des colonnes, transformations batch en mémoire, pipelines de décompression/compression,
certaines charges de réplication/copie, et tout ce qui ressemble à « toucher beaucoup de RAM une fois ».

Un indicateur courant : l’utilisation CPU n’est pas saturée, mais le débit stagne ; les compteurs perf montrent des stalls mémoire ; augmenter les threads n’aide plus ;
et ajouter des cœurs déplace à peine l’aiguille.

Machines à forts nombres de cœurs et boîtes NUMA larges qui étaient à la peine sur DDR4

Les CPU modernes peuvent lancer un nombre absurde de requêtes mémoire en attente vers le contrôleur mémoire. Avec assez de cœurs, la DDR4 peut devenir le goulot,
surtout dans les systèmes multi-socket où les accès mémoire distants sont déjà coûteux.

La DDR5 plus une population correcte des canaux peut maintenir ces cœurs alimentés—à condition de ne pas saboter cela avec un DIMM par socket « parce que les achats ».

Charges où la capacité évite le paging et le churn du cache

Encore : la capacité, c’est la performance. Si la DDR5 vous permet d’acheter 512 Go au lieu de 256 Go à un coût raisonnable, et que cela empêche des tempêtes de swap ou des lectures disque répétées,
vous avez amélioré la performance d’ordres de grandeur. Pas des pourcentages. Des ordres.

Certains scénarios de virtualisation et de consolidation

La consolidation augmente la contention mémoire. La DDR5 peut vous donner plus de marge—bande passante et capacité—pour que les voisins bruyants soient moins bruyants.
Mais les gros gains viennent toujours d’un pinning NUMA conscient et d’éviter le thrash causé par l’overcommit.

Ce qui ne s’accélère pas (et parfois se dégrade)

Les chemins critiques sensibles à la latence peuvent ne pas s’améliorer

Si votre chemin critique est dominé par des misses de cache avec de petits accès aléatoires, la DDR5 peut montrer peu d’avantage comparée à une bonne DDR4.
Elle peut aussi régresser si les timings DDR5 sont plus lâches et que l’entraînement mémoire de la plateforme est conservateur.

Si votre P99 est ce que vous vendez, arrêtez de penser en « MT/s ». Commencez à penser en « latence en queue sous charge avec une localité NUMA réaliste ».

La performance mono-thread ne change pas automatiquement

Un thread unique qui tient principalement dans le cache ne s’en souciera pas. Un thread unique qui manque le cache mais est limité par la latence ne s’en souciera pas beaucoup non plus.
La DDR5 ne réécrit pas la physique. Vos options de compilation comptent toujours. Votre contention sur les locks compte toujours. Vos appels système comptent toujours.

Les goulots de stockage restent des goulots de stockage

Si vous attendez des IO disque ou réseau, une DRAM plus rapide ne résout pas cela. Elle peut même le rendre plus évident en accélérant tout jusqu’au goulot.
C’est du progrès, mais ce n’est pas l’histoire d’upgrade que vous avez vendue.

Un mauvais placement NUMA peut effacer les gains de la DDR5

L’accès mémoire distant sur les systèmes multi-socket est une taxe. Parfois une taxe brutale. La DDR5 ne l’élimine pas ; elle peut juste en changer la pente.
Si votre charge bavarde beaucoup entre NUMA, vous pouvez acheter de la mémoire plus rapide et perdre quand même face à un système DDR4 bien épinglé.

Blague #1 : la DDR5 ne corrigera pas votre architecture, mais elle fera échouer votre architecture plus vite. C’est quand même une forme d’observabilité.

Réalité plateforme : IMC, canaux, rangs et « vous avez peuplé les mauvais emplacements »

La vitesse DRAM n’est pas seulement le DIMM. C’est le contrôleur mémoire intégré du CPU (IMC), le routage de la carte mère, l’entraînement BIOS,
le nombre de canaux, le nombre de DIMM par canal (DPC), et la topologie de rangs.

Canaux : le levier le plus important que la plupart des gens sous-utilisent par accident

Sur les serveurs, vous voulez généralement peupler tous les canaux mémoire par socket pour la bande passante et un accès équilibré. Des canaux à moitié remplis peuvent couper la bande passante
de façon dramatique même si les DIMM sont « rapides ». C’est le désastre silencieux : vous avez payé pour DDR5-5600 et installé de façon à vous comporter comme « DDR-n’importe-quoi,
mais affamé ».

DIMM par canal (1DPC vs 2DPC) : les classes de vitesse ne sont pas des souhaits

Beaucoup de plateformes réduisent le débit de données maximal quand vous exécutez 2DPC ou utilisez des DIMM de très haute capacité. Ce n’est pas une sabotage fabricant ; c’est l’intégrité du signal.
La question n’est donc pas « Mon DIMM est-il annoncé 5600 ? » mais « Avec ma population et mon nombre de rangs, à quelle vitesse la plateforme s’entraîne-t-elle réellement ? »

Rangs : capacité et parallélisme contre complexité d’entraînement

Plus de rangs peuvent améliorer la performance en augmentant le parallélisme—jusqu’à un certain point. Cela peut aussi mettre à rude épreuve les marges d’entraînement et réduire la fréquence maximale.
Pour certaines charges, une fréquence légèrement plus basse avec plus de rangs et plus de capacité l’emporte. Pour d’autres, moins de rangs à fréquence plus élevée gagne.
La seule réponse honnête est : mesurez sur votre charge.

ECC, RDIMM vs UDIMM : choisissez la classe qui correspond à votre profil de risque

Les serveurs utilisent couramment des RDIMM (registered) pour une plus grande capacité et une meilleure intégrité du signal. Les stations de travail peuvent utiliser des UDIMM.
Mélanger les classes est généralement incompatible. Mélanger les fournisseurs et profils SPD peut marcher, mais c’est une excellente façon de finir en train de tourner au plus petit dénominateur commun.

Valeurs par défaut du BIOS : « Auto » n’est pas une stratégie de performance

« Auto » dans le BIOS choisit souvent la stabilité et la compatibilité plutôt que la performance maximale. Ce n’est pas malveillant ; c’est raisonnable.
Mais si vous avez besoin de résultats cohérents, vous devez standardiser le firmware, les profils mémoire et les réglages d’alimentation.

Faits intéressants et contexte historique (ce qui explique les bizarreries d’aujourd’hui)

• Fait 1 : Le « double data rate » du DDR faisait initialement référence au transfert sur les deux flancs d’horloge ; l’industrie a étiré cette idée depuis.
• Fait 2 : L’ère grand public du DDR3 a normalisé le « concours de fréquences », même lorsque la latence réelle en nanosecondes n’avait pas beaucoup évolué.
• Fait 3 : Le passage aux contrôleurs mémoire intégrés (popularisés sur x86 à la fin des années 2000) a rendu le comportement mémoire beaucoup plus dépendant du CPU et du socket.
• Fait 4 : Les valeurs de vitesse mémoire (MT/s) sont des transferts par seconde, pas des MHz d’horloge ; cette confusion refuse de disparaître dans les diapos commerciales.
• Fait 5 : Les sous-canaux doubles 32 bits de la DDR5 ont été conçus pour améliorer l’efficacité sur de courtes rafales—important à mesure que les CPU émettent plus de requêtes concurrentes et plus petites.
• Fait 6 : La DDR5 a introduit des PMIC sur DIMM, déplaçant une partie de la régulation d’alimentation de la carte mère vers le module pour une meilleure stabilité à haute vitesse.
• Fait 7 : L’on-die ECC dans la DDR5 est interne au dispositif DRAM ; il ne remplace pas la visibilité ou les garanties de correction de l’ECC système.
• Fait 8 : Les plateformes serveur réduisent souvent la fréquence mémoire avec plus de DIMM par canal ; la « vitesse supportée » est une matrice, pas un seul nombre.
• Fait 9 : Beaucoup de gains de performance attribués à la « RAM plus rapide » sont en réalité dus à « plus de RAM », car éviter le paging est l’optimisation la plus rapide connue des humains.

Feuille de route pour un diagnostic rapide

Quand quelqu’un dit « Nous sommes passés à la DDR5 et ce n’est pas plus rapide », faites ceci avant d’engager la guerre sur Slack.

Première étape : confirmez que vous êtes réellement en DDR5 à la vitesse et topologie attendues

• Vérifiez la vitesse mémoire entraînée, la population des canaux, les nœuds NUMA, et si vous n’avez pas accidentellement réduit la bande passante en peuplant mal les slots.
• Vérifiez la cohérence de la version BIOS sur l’ensemble de la flotte. L’entraînement mémoire change entre les versions plus que les gens ne veulent l’admettre.

Deuxième étape : identifiez la classe de goulot (CPU, bande passante mémoire, latence mémoire, IO, contention sur locks)

• Utilisez des compteurs perf/topdown si disponibles, ou au minimum regardez les changements de contexte, la file d’exécution et les défauts de page.
• Mesurez la bande passante mémoire avec un microbenchmark seulement comme contrôle de cohérence, pas comme preuve que votre appli en profite.

Troisième étape : vérifiez la localité NUMA et le placement des pages sous charge réelle

• Si les accès NUMA distants sont élevés, vous avez un problème de placement, pas un problème DDR5.
• Si THP ou les réglages de huge pages ont changé avec la nouvelle plateforme, votre profil de latence peut aussi avoir changé.

Quatrième étape : vérifiez l’alimentation et les gouverneurs de fréquence

• Les modes d’alimentation CPU et les fonctionnalités d’alimentation mémoire peuvent modifier la latence et le débit. « Économie d’énergie » n’est pas gratuit.

Cinquième étape : comparez pommes avec pommes

• Même version de noyau, même microcode, mêmes réglages BIOS, mêmes flags de compilation, mêmes limites de conteneur, mêmes flags JVM, tout identique.

Tâches pratiques : commandes, sorties, ce que ça signifie, et la décision à prendre

Vous voulez arrêter de deviner. Bien. Voici des tâches terrain à exécuter sur Linux pour vérifier ce que fait la DDR5, quel est le goulot, et quoi changer.
Chaque tâche inclut : une commande, une sortie d’exemple, ce que cela signifie, et la décision à prendre.

Task 1: Confirm installed memory type and configured speed

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Locator:|Type:|Speed:|Configured Memory Speed:|Rank:|Manufacturer:|Part Number:' | head -n 20
Locator: DIMM_A1
Type: DDR5
Speed: 5600 MT/s
Configured Memory Speed: 5200 MT/s
Rank: 2
Manufacturer: Micron
Part Number: MTC20C2085S1EC56BA1
Locator: DIMM_B1
Type: DDR5
Speed: 5600 MT/s
Configured Memory Speed: 5200 MT/s
Rank: 2
Manufacturer: Micron
Part Number: MTC20C2085S1EC56BA1

Ce que cela signifie : Les DIMM sont annoncés 5600, mais la plateforme les a entraînés à 5200. C’est normal dans certaines conditions de population/rang.

Décision : Si la performance est inférieure à l’attendu, vérifiez la population (1DPC vs 2DPC), les mises à jour BIOS, et la matrice de vitesse supportée du CPU avant de blâmer la DDR5.

Task 2: Confirm NUMA topology and CPU layout

cr0x@server:~$ lscpu | egrep 'Model name|Socket|NUMA node|CPU\(s\)|Thread|Core|L3 cache'
Model name:                         AMD EPYC 9354P 32-Core Processor
CPU(s):                             64
Thread(s) per core:                 2
Core(s) per socket:                 32
Socket(s):                          1
L3 cache:                           256 MiB
NUMA node(s):                       4

Ce que cela signifie : Même une machine « mono-socket » peut avoir plusieurs nœuds NUMA. La localité mémoire existe toujours.

Décision : Planifiez le pinning/placement. Si votre appli suppose UMA, testez l’interleaving vs le binding NUMA explicite.

Task 3: See memory attached per NUMA node

cr0x@server:~$ numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0-15
node 0 size: 96000 MB
node 0 free: 82000 MB
node 1 cpus: 16-31
node 1 size: 96000 MB
node 1 free: 84000 MB
node 2 cpus: 32-47
node 2 size: 96000 MB
node 2 free: 83000 MB
node 3 cpus: 48-63
node 3 size: 96000 MB
node 3 free: 85000 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 : La mémoire est bien équilibrée. Les distances montrent le coût local vs distant.

Décision : Si un nœud est à court de mémoire ou si les distances sont asymétriques, enquêtez sur les modes BIOS « NUMA par socket », la population mémoire, ou un DIMM/channel défaillant.

Task 4: Check whether you’re paging (the silent performance killer)

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 8123456  84216 9213344    0    0     1     3  812 1021 12  3 85  0  0
 4  0      0 8119900  84216 9218800    0    0     0     0  901 1402 18  4 78  0  0
 6  1      0 8091200  84216 9240100    0    0     0   120 1102 1801 25  6 68  1  0
 3  0      0 8100012  84216 9230020    0    0     0     0  950 1500 20  5 75  0  0
 2  0      0 8098890  84216 9238000    0    0     0     0  880 1320 16  4 80  0  0

Ce que cela signifie : si/so sont à zéro, donc pas d’activité de swap. Bien.

Décision : Si si/so sont non nuls sous charge, la DDR5 ne vous sauvera pas. Corrigez la taille mémoire, les fuites, ou l’overcommit d’abord.

Task 5: Detect major page faults (working set doesn’t fit)

cr0x@server:~$ pidstat -r -p 1287 1 3
Linux 6.5.0 (server) 	01/09/2026 	_x86_64_	(64 CPU)

#      Time   UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
12:01:11   1001      1287   1200.00      0.00  32.0g   18.4g  14.5  postgres
12:01:12   1001      1287   1100.00      4.00  32.0g   18.4g  14.5  postgres
12:01:13   1001      1287    900.00      8.00  32.0g   18.4g  14.5  postgres

Ce que cela signifie : Les fautes majeures (majflt/s) indiquent des fetchs depuis disque. C’est du poison pour la latence.

Décision : Réduisez la pression mémoire, corrigez le dimensionnement du cache, ou ajoutez de la RAM. La bande passante DDR5 est hors sujet si vous attendez du stockage pour des pages.

Task 6: Measure remote NUMA accesses for the workload

cr0x@server:~$ sudo perf stat -a -e node-loads,node-load-misses,node-stores,node-store-misses -I 1000 -- sleep 3
#           time             counts unit events
     1.000270280      9,812,330      node-loads
     1.000270280      1,921,004      node-load-misses
     1.000270280      4,102,882      node-stores
     1.000270280        622,110      node-store-misses

     2.000544721     10,010,220      node-loads
     2.000544721      2,012,889      node-load-misses
     2.000544721      4,221,930      node-stores
     2.000544721        690,332      node-store-misses

     3.000812019      9,900,120      node-loads
     3.000812019      1,980,001      node-load-misses
     3.000812019      4,180,010      node-stores
     3.000812019        650,210      node-store-misses

Ce que cela signifie : Des « misses » significatifs peuvent suggérer des accès à des nœuds distants ou une localité sous-optimale, selon le mapping de la plateforme.

Décision : Si les accès distants sont élevés durant le chemin critique de l’appli, liez processus/threads et mémoire, ou ajustez l’allocateur/les paramètres JVM NUMA.

Task 7: Quick check of memory bandwidth ceiling (sanity test)

cr0x@server:~$ sudo apt-get -y install mbw >/dev/null 2>&1
cr0x@server:~$ mbw -n 3 -t 4 1024
0	Method: MEMCPY	Elapsed: 0.30122	MiB: 1024.00000	Copy: 3398.112 MiB/s
1	Method: MEMCPY	Elapsed: 0.29988	MiB: 1024.00000	Copy: 3413.556 MiB/s
2	Method: MEMCPY	Elapsed: 0.30010	MiB: 1024.00000	Copy: 3411.020 MiB/s

Ce que cela signifie : Ce n’est pas votre application. C’est un test plafond grossier. S’il est extraordinairement bas, quelque chose est mal configuré.

Décision : Si la bande passante est bien en dessous des attentes pour la plateforme, inspectez la population des canaux, les réglages d’alimentation BIOS, et si la mémoire s’est entraînée à un taux bas.

Task 8: Check CPU frequency governor and current policy

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

Ce que cela signifie : Vous êtes en mode powersave. Votre upgrade DDR5 vient de rencontrer son prédateur naturel : « politique d’énergie ».

Décision : Sur des nœuds critiques pour la performance, passez au gouverneur performance (ou une politique contrôlée via tuned) et validez la thermique.

Task 9: Inspect memory errors and ECC events (if supported)

cr0x@server:~$ sudo dmesg -T | egrep -i 'edac|mce|ecc|memory error' | tail -n 10
[Thu Jan  9 12:02:11 2026] EDAC MC0: 1 CE memory scrubbing error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x12345 offset:0x0 grain:64 syndrome:0x0)

Ce que cela signifie : Des erreurs correctibles existent. Ce n’est pas « OK pour toujours ». C’est une tendance à surveiller.

Décision : Suivez le taux de CE. S’il augmente, remplacez le DIMM de manière proactive. Les problèmes de stabilité DDR5 peuvent se manifester par des « crashes applis aléatoires ».

Task 10: Verify transparent huge pages (THP) mode

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

Ce que cela signifie : THP est activé en permanence. Certaines bases de données l’aiment, d’autres le détestent, beaucoup le tolèrent jusqu’à ce qu’elles ne le tolèrent plus.

Décision : Si vous observez des pics de latence ou de la CPU liée à la compaction mémoire, testez « madvise » ou « never » et mesurez. Ne faites pas du cargo-cult : benchmarquez votre charge.

Task 11: Check per-process NUMA memory placement

cr0x@server:~$ sudo numastat -p 1287
Per-node process memory usage (in MBs) for PID 1287 (postgres)
                           Node 0          Node 1          Node 2          Node 3           Total
                  --------------- --------------- --------------- --------------- ---------------
Huge                      1200.00           10.00           15.00           20.00         1245.00
Heap                      8000.00         2500.00         2600.00         2400.00        15500.00
Stack                        5.00            5.00            5.00            5.00           20.00
Private                     50.00           30.00           25.00           28.00          133.00
---------------- --------------- --------------- --------------- --------------- ---------------
Total                     9255.00         2545.00         2645.00         2453.00        16898.00

Ce que cela signifie : La mémoire est répartie entre les nœuds. Cela peut aller, ou représenter une taxe d’accès distant selon le placement des threads.

Décision : Si les threads du processus s’exécutent principalement sur le Node 0 mais que la mémoire est répartie, pinnez et allouez localement (numactl, cgroups cpuset, systemd CPUAffinity), puis retestez.

Task 12: Confirm memory interleaving / NUMA settings impact (A/B test)

cr0x@server:~$ numactl --cpunodebind=0 --membind=0 ./my_benchmark --seconds 10
ops/sec: 1824000
p99_us: 410

cr0x@server:~$ numactl --cpunodebind=0 --interleave=all ./my_benchmark --seconds 10
ops/sec: 1689000
p99_us: 520

Ce que cela signifie : Pour ce benchmark, le binding local bat l’interleaving : débit plus élevé et meilleur P99.

Décision : Préférez le binding NUMA local pour les charges sensibles à la latence. Utilisez l’interleaving pour les workloads heavy-bandwidth si cela améliore le débit global.

Task 13: Check run queue pressure (CPU contention looks like “memory is slow”)

cr0x@server:~$ uptime
 12:04:44 up 18 days,  3:22,  2 users,  load average: 96.12, 88.40, 70.03

Ce que cela signifie : La charge moyenne dépasse largement les threads CPU ? Vous avez de la contention d’ordonnancement, pas un débat DDR4/DDR5.

Décision : Réduisez la contention : redimensionnez les pools de threads, corrigez les voisins bruyants, allouez plus de CPU, ou séparez les charges. Les upgrades mémoire ne régleront pas une file d’exécution saturée.

Task 14: Look for memory stalls at the CPU level (high-level view)

cr0x@server:~$ sudo perf stat -a -e cycles,instructions,cache-misses,LLC-load-misses -- sleep 2
 Performance counter stats for 'system wide':

    8,212,334,100      cycles
    5,100,882,220      instructions              #    0.62  insn per cycle
      122,110,220      cache-misses
       45,990,112      LLC-load-misses

       2.001153527 seconds time elapsed

Ce que cela signifie : Faible IPC plus beaucoup de cache misses suggèrent que les stalls mémoire sont significatifs.

Décision : Si la DDR5 est le seul changement, confirmez toujours le NUMA et la population des canaux. Si les stalls dominent, la bande passante DDR5 peut aider—si vous savez l’alimenter efficacement.

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

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

Une plateforme financière a déployé de nouveaux nœuds compute annoncés « DDR5-5600, tout plus rapide ». Le plan de déploiement était conservateur : canary, puis vidage progressif
des anciens nœuds. Bonne démarche. Les résultats furent déroutants : la latence moyenne s’améliora légèrement, mais le P99 empirait, et le « pire » se concentrait autour des GC.

L’hypothèse erronée était subtile : ils avaient supposé qu’« un socket » voulait dire « un domaine NUMA ». Les nouveaux CPU exposaient plusieurs nœuds NUMA pour la topologie interne,
et la JVM allouait joyeusement à travers eux alors que les threads applicatifs étaient épinglés (via les cpusets des conteneurs) principalement sur un nœud. Le trafic mémoire distant a grimpé.

L’incident n’a pas été une panne totale, mais suffisant pour déclencher des pages SLO pendant une fenêtre de trading chargée. Le chat d’escalade blâmait prévisiblemnt les timings DDR5,
puis le noyau, puis « peut-être les drivers NIC ». Pendant ce temps, les compteurs perf hurlaient silencieusement à propos des node misses.

La correction fut ennuyeuse et immédiate : aligner le pinning CPU avec la politique mémoire, et arrêter d’étaler les allocations entre nœuds par accident. Ils ont testé
numactl --cpunodebind vs interleave pour le service, puis l’ont codifié dans des overrides systemd pour ces hôtes.
Après cela, les nœuds DDR5 se sont comportés comme l’upgrade pour lequel ils avaient payé : un débit légèrement supérieur, et le P99 est revenu à la normale.

Leçon : la DDR5 n’a rien cassé. Leur modèle mental l’a fait.

Mini-récit 2 : L’optimisation qui a provoqué l’effet inverse

Une entreprise média exploitait une flotte de workers de transcodage. Ces workloads étaient gourmands en bande passante : décodage d’images, déplacement de buffers, écriture de sorties.
Ils sont passés à la DDR5 puis ont décidé de « l’aider » en activant tous les knobs perf possibles dans le BIOS : profils mémoire agressifs, clocks fabric maximales,
et réglages d’alimentation permissifs. Les benchs en labo calme étaient excellents.

En production, sous les températures d’été et le flux d’air réel des racks, ils ont commencé à voir des crashes rares des workers. Pas fréquents, mais suffisants pour gêner :
retries, timeouts de jobs, flaps sporadiques de nœuds. Les logs d’erreur ressemblaient à des bugs logiciels—segfaults à des endroits qui « ne plantent jamais », sorties corrompues,
et rapports occasionnels de MCE kernel.

Ils ont rollbacké le logiciel. Toujours présent. Ils ont changé de version de noyau. Toujours présent. Finalement, quelqu’un a corrélé le taux de crashs avec des racks spécifiques
et a remarqué que la température des DIMM flirtait avec les marges. Le profil mémoire agressif avait rogné la marge de stabilité pour gagner quelques pourcents de débit.

Ils ont reculé à un profil mémoire JEDEC/serveur validé et renforcé la surveillance des erreurs correctibles ECC. Le débit a légèrement baissé dans les benchs,
mais le taux de complétion des jobs a augmenté et les tempêtes de retries ont cessé. Personne ne regrette les 3 % en plus quand la tempête d’alertes a disparu.

Leçon : on ne peut pas overclocker la fiabilité en production. La production est l’endroit où vos fantasmes de bench se font auditer.

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

Une entreprise SaaS a planifié une actualisation DDR4 → DDR5 pour les réplicas de base de données en premier. L’équipe a fait quelque chose d’impopulaire : elle a créé une checklist
d’acceptation matérielle et a refusé de déployer des nœuds qui ne la passaient pas. Pas « on réparera plus tard ». Ils bloquaient l’intégration.

Lors de l’intégration, un lot de serveurs s’est entraîné à une vitesse mémoire inférieure à l’attendue. Pas d’erreurs, juste une vitesse configurée plus lente.
Le fournisseur disait que c’était « dans les spécifications ». L’équipe n’a pas discuté ; elle a mesuré. Ils ont comparé des workloads identiques entre nœuds et constaté que ces unités
avaient une bande passante mémoire matériellement plus basse. Pas catastrophique, mais suffisant pour fausser le lag de réplication lors des pics.

La cause racine s’est révélée être une population DIMM incohérente avec les emplacements recommandés par la carte mère pour une utilisation complète des canaux.
L’atelier de montage avait utilisé « les slots les plus simples » et avait obtenu un POST réussi, donc tout le monde a supposé que c’était OK.

Parce que l’équipe avait un test d’acceptation standard (vérif dmidecode, sanity check bande passante, check équilibre NUMA), ils l’ont détecté avant la production.
La correction a été littéralement de déplacer les DIMM. Le bénéfice fut de ne pas déclencher la garde.

Leçon : l’outil de performance le plus efficace est une checklist qui bloque le matériel défectueux avant qu’il ne devienne « le problème du logiciel ».

Erreurs courantes : symptômes → cause racine → correction

1) « La mise à niveau DDR5 n’a rien fait »

Symptômes : Débit inchangé, CPU non saturé, perf montre des stalls, les benchmarks se ressemblent.

Cause racine : La charge n’est pas limitée par la bande passante mémoire ; elle est limitée par la latence, les locks, ou les IO. Ou la mémoire s’est entraînée à une vitesse plus basse à cause du 2DPC.

Correction : Classifiez le goulot d’abord (perf, vmstat, iostat). Si c’est bandwidth-bound, validez la vitesse entraînée et la population des canaux ; sinon dépensez ailleurs.

2) « Nous avons un P99 pire après le passage à la DDR5 »

Symptômes : La moyenne s’améliore légèrement, la latence en queue se dégrade ; pics autour du GC ou des charges de pointe.

Cause racine : Régression de la localité NUMA ; THP/huge pages modifiés ; politique d’alimentation CPU changée ; l’entraînement mémoire a choisi des timings conservateurs.

Correction : Vérifiez numastat par process, liez threads+mémoire, validez le mode THP, définissez un gouverneur CPU prévisible, et comparez les réglages BIOS entre anciens/nouveaux nœuds.

3) « Crashes/segfaults aléatoires après activation d’un profil mémoire plus rapide »

Symptômes : Crashes rares, sorties corrompues, logs MCE/EDAC, comportement instable sous chaleur.

Cause racine : Stabilité marginale due à des profils XMP/EXPO agressifs, à la thermique, ou à des DIMM mélangés forçant un entraînement étrange.

Correction : Exécutez en profil JEDEC/serveur validé, mettez à jour le BIOS, assurez le refroidissement, surveillez les taux CE, et remplacez les DIMM suspects.

4) « La bande passante mémoire semble faible sur un serveur DDR5 neuf »

Symptômes : Les microbenchmarks sous-performent ; l’augmentation des threads n’accroît pas le débit.

Cause racine : Canaux manquants (mauvaise population de slots), BIOS réglé sur une vitesse basse à cause de DPC/rangs, ou canal désactivé par une panne matérielle.

Correction : Comparez le mapping dmidecode locator avec le guide slots du fournisseur, vérifiez la vitesse entraînée BIOS, faites une validation par canal, reseatez les DIMM, ouvrez un ticket matériel si nécessaire.

5) « Les réplicas de base de données accusent plus de lag sur les nœuds DDR5 »

Symptômes : Le lag de réplication augmente ; CPU OK ; disque OK.

Cause racine : Sensibilité à la latence mémoire (index, comportement du buffer pool), mauvais placement NUMA, ou paramètres noyau différents affectant l’allocateur.

Correction : Assurez-vous que l’allocation mémoire DB est locale au(x) nœud(s) NUMA où tournent les threads, tunez les huge pages, et confirmez que les affinités IRQ ne volent pas du CPU.

6) « L’hôte de virtualisation devient bruyant après le refresh »

Symptômes : Variance de performance des VM augmente ; IO wait intermittent ; activité de swap sur l’hôte.

Cause racine : Overcommit augmenté parce que « nous avons maintenant de la RAM plus rapide », interactions ballooning/THP, ou contention de bande passante mémoire due à la consolidation.

Correction : Reconsidérez les ratios de consolidation, limitez les workloads bruyants, alignez vCPU/vNUMA au NUMA physique, et surveillez agressivement swap/fautes de page.

Blague #2 : Acheter de la DDR5 pour un hôte en thrash de swap, c’est comme installer un turbo sur une voiture avec quatre pneus à plat. Techniquement impressionnant, pratiquement immobile.

Listes de vérification / plan pas à pas

Étape par étape : décider si la DDR5 en vaut la peine pour votre charge

1. Mesurez votre goulot actuel. Si vous ne pouvez pas dire « CPU-bound » vs « memory-bound » vs « IO-bound », vous achetez émotionnellement.
2. Capturez les métriques de base. Débit, latence P50/P95/P99, utilisation CPU, fautes de page, et localité NUMA sous charge réelle.
3. Validez la topologie mémoire sur la baseline. Canaux peuplés, vitesse entraînée, nœuds NUMA.
4. Exécutez un canary sur le matériel DDR5. Même logiciel, même noyau, même config. Si vous changez dix choses, vous n’apprenez rien.
5. Comparez la latence en queue, pas seulement les moyennes. Si votre business est orienté utilisateur, le P99 est la vérité pour laquelle vous payez.
6. Décidez selon le déplacement de la contrainte. Si la DDR5 repousse le goulot (par ex. moins de stalls mémoire, le CPU devient le limiteur), c’est un gain.

Étape par étape : déployer la DDR5 en sécurité en production

1. Standardisez BIOS/firmware. Mêmes versions sur toute la flotte. Les résultats d’entraînement mémoire sont réels.
2. Utilisez des profils mémoire validés. Préférez la stabilité en production. Si vous devez tuner, faites-le avec burn-in et validation thermique.
3. Peuplez correctement les canaux. Suivez le guide de la carte. Ne laissez pas l’atelier de montage improviser les emplacements.
4. Activez l’ECC quand c’est approprié. Si la plateforme le supporte, utilisez-le. Et surveillez vraiment les logs EDAC/MCE.
5. Définissez une politique d’alimentation prévisible. Verrouillez les gouverneurs/profils tuned pour ne pas benchmarquer dans un mode et courir un autre.
6. Documentez les attentes NUMA. Combien de nœuds, comment les workloads doivent binder, et à quoi ressemble un bon numastat.
7. Testez d’acceptation chaque nœud. Vérif dmidecode, équilibre NUMA, sanity check bande passante, et un court stress test.
8. Canary et déploiement progressif. Si vous ne canaryez pas les changements matériels, vous opérez sur la foi.

Checklist d’acceptation production (rapide)

• La vitesse entraînée correspond à l’attendu pour la matrice de population (pas l’autocollant sur le DIMM)
• Tous les canaux peuplés selon les recommandations du fournisseur
• Nœuds NUMA équilibrés ; pas de « mémoire manquante » par nœud
• Pas d’erreurs EDAC/MCE durant le stress
• Gouverneur CPU et modes d’alimentation BIOS conformes à la politique de performance
• Le p99 applicatif sous charge respecte le SLO

FAQ

1) La DDR5 est-elle toujours plus rapide que la DDR4 ?

Non. La DDR5 est en général meilleure pour les charges gourmandes en bande passante, mais les charges sensibles à la latence peuvent voir peu de gains voire régresser si les timings/entraînement/politique d’alimentation diffèrent.

2) Que regarder en premier : MT/s ou CAS latency ?

Aucun des deux en premier. Regardez votre goulot. Ensuite : la bande passante (MT/s, canaux) compte pour le streaming ; la vraie latence en nanosecondes compte pour le pointer-chasing.
CAS seul n’est pas « la latence ».

3) Pourquoi dmidecode affiche « Configured Memory Speed » plus bas que la cote du DIMM ?

Parce que la plateforme l’a entraîné plus bas en fonction du nombre de DIMM par canal, de la charge de rangs, du support CPU, de la politique BIOS, ou de l’intégrité du signal. La cote est ce que le module peut faire ; le système décide ce qu’il fera.

4) La DDR5 aide-t-elle pour le gaming ou les apps desktop ?

Parfois, modestement. Beaucoup de jeux sont limités par le GPU ou favorisent le cache. Vous remarquerez la DDR5 davantage quand vous êtes limité CPU à des cibles FPS élevées ou quand des tâches de fond se disputent la bande passante.

5) La DDR5 aide-t-elle les bases de données ?

Ça dépend. Les scans analytiques et workloads colonne aiment souvent la bande passante. Les hot paths OLTP peuvent être sensibles à la latence et au NUMA. Les augmentations de capacité peuvent être le plus gros gain si elles évitent les IO.

6) L’on-die ECC est-il équivalent à la mémoire ECC ?

Non. L’on-die ECC corrige certains problèmes internes DRAM mais n’offre pas la même détection/correction bout en bout ni le journal système que fournit l’ECC système.
Si vous tenez à la fiabilité, achetez des DIMM ECC sur une plateforme qui les supporte.

7) Dois-je activer les profils XMP/EXPO-like sur des serveurs ?

Généralement non, sauf si vous avez une configuration validée et êtes prêt à assumer le risque de stabilité et thermique.
En production, on préfère le « prévisible » au « marginalement plus rapide dans un benchmark ».

8) Combien de DIMM devrais-je installer par socket ?

Remplissez d’abord tous les canaux. Ensuite, considérez le compromis 1DPC vs 2DPC. Plus de DIMM augmente la capacité mais peut réduire la vitesse entraînée. Suivez les règles de population de la plateforme.

9) La DDR5 peut-elle résoudre mon usage de swap ?

Non. Si vous swappez, vous avez besoin de plus de RAM, de réduire l’usage mémoire, ou de changer la politique d’overcommit. La bande passante plus rapide de la DDR5 ne rend pas le paging disque « acceptable ».

10) Quelle est la preuve la plus simple que je suis limité par la bande passante mémoire ?

Sous charge, vous observez un faible IPC, des taux élevés de cache miss, et l’ajout de threads cesse d’augmenter le débit. Ensuite, ajouter des canaux/vitesse mémoire aide dans des tests A/B contrôlés.
Si votre goulot est le verrouillage ou l’IO, la DDR5 ne le fera pas bouger.

Prochaines étapes réalisables cette semaine

Voici l’ordre pratique d’opérations qui évite les upgrades placebo coûteux :

1. Exécutez les vérifications de topologie (dmidecode, lscpu, numactl –hardware) sur un nœud ancien et un nœud DDR5. Confirmez canaux, vitesse entraînée, forme NUMA.
2. Réalisez un test de charge réaliste et capturez p50/p95/p99, CPU, fautes de page, et compteurs perf. N’utilisez pas un microbenchmark comme unique preuve.
3. Corrigez les tueurs faciles : activité de swap, mauvais gouverneur CPU, et mauvais placement NUMA. Ceux-ci effacent régulièrement les gains DDR5.
4. Standardisez le firmware et la politique BIOS sur la flotte. Les « résultats d’entraînement snowflake » font apparaître des variances de performance inexplicables.
5. Décidez selon le déplacement de la contrainte : si la DDR5 repousse votre goulot (moins de stalls mémoire, débit plus élevé), étendez-la. Sinon, dépensez sur CPU, IO, ou capacité.

Une citation à garder sur le mur, car elle explique la moitié de l’ingénierie de performance et la plupart des opérations : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

La DDR5 est une bonne technologie. Votre travail est de vous assurer qu’elle s’applique au problème que vous avez réellement, pas au problème que votre diapositive d’achats souhaiterait que vous ayez.