Si vous vous êtes déjà retrouvé devant un tableau de bord où le CPU semble « correct », les disques semblent « corrects » et pourtant l’application rampe
comme si elle poussait un réfrigérateur en côte, vous comprenez déjà pourquoi Opteron comptait. Ce n’était pas « juste un autre CPU ». C’était AMD entrant
dans la salle serveurs — là où les budgets sont réels et les excuses peu tolérées — et offrant aux administrateurs des commandes qui faisaient réellement la différence.
Opteron n’a pas gagné parce qu’il était mignon. Il a gagné parce qu’il a fait tenir le système : la latence mémoire a chuté, la mise à l’échelle multi-socket a cessé
d’être un projet de science, et le 64-bit est arrivé sans forcer l’industrie à brûler sa pile logicielle.
La porte VIP : pourquoi les serveurs étaient la seule salle qui comptait
Les consommateurs achètent des CPU selon l’ambiance et les benchmarks. Les entreprises les achètent selon les résultats : latence prévisible, mise à l’échelle stable,
et capacité à mettre à niveau sans réécrire une décennie de logiciels. C’est pour cela que le marché serveur est la porte VIP. Une fois que vous êtes approuvé en production,
votre logo passe de « intéressant » à « fournisseur approuvé ». Et « fournisseur approuvé » est là où l’argent se trouve.
Au début des années 2000, Intel détenait le récit dans les serveurs. « Xeon » voulait dire sûr. « Itanium » était présenté comme l’avenir. AMD était l’alternative
combative — souvent excellente, parfois ignorée, rarement conviée à la grande table. Opteron a changé la géométrie sociale.
L’essentiel est qu’Opteron n’a pas simplement essayé de battre Intel sur le CPU brut. Il a attaqué la performance système là où les charges réelles souffrent :
bande passante mémoire, latence mémoire, cohérence multi-socket et compatibilité d’évolution. Le résultat n’était pas simplement « plus rapide ». Le résultat était moins
de mauvaises surprises à 2h du matin.
Faits historiques qui expliquent le basculement (pas de mythologie)
- Opteron lancé en 2003, et il a apporté x86-64 (AMD64) aux serveurs tout en gardant le logiciel 32-bit opérationnel.
- Intel avait initialement parié sur Itanium (EPIC/IA-64) pour l’entreprise 64-bit, en s’attendant à ce que x86 disparaisse des serveurs haut de gamme.
- Le contrôleur mémoire intégré d’AMD a déplacé l’accès mémoire hors du northbridge, réduisant la latence et augmentant la bande passante pour les charges réelles.
- HyperTransport a remplacé l’ancien modèle de front-side bus pour les liens CPU-à-CPU et CPU-à-chipset, aidant la mise à l’échelle multi-socket.
- Les distributions Linux ont adopté AMD64 tôt, et ça comptait : les équipes ops pouvaient tester et déployer sans attendre des écosystèmes propriétaires.
- Les grands OEM ont livré des serveurs Opteron — le signal d’achat qui dit « ce n’est pas un projet de foire scientifique ».
- La virtualisation a obtenu une piste pratique : même avant la maturité des extensions matérielles de virtualisation, AMD64 a rendu moins pénible la gestion d’espaces d’adresses et la consolidation.
- NUMA a cessé d’être théorique : les serveurs x86 multi-socket sont devenus clairement NUMA, et le logiciel a dû l’admettre.
- Intel a plus tard adopté essentiellement le même modèle 64-bit (Intel 64/EM64T), validant la stratégie d’AMD : faire évoluer x86, ne pas le remplacer.
Ce qu’Opteron a changé techniquement — et pourquoi les opérateurs s’en souciaient
1) Le contrôleur mémoire intégré : moins de mensonges entre vous et la RAM
Dans l’ancien monde du front-side bus (FSB) partagé, les CPU étaient comme des colocataires partageant un couloir étroit vers la cuisine. Tout le monde pouvait cuisiner.
Juste pas en même temps. Opteron a mis la cuisine à l’intérieur de chaque package CPU en intégrant le contrôleur mémoire. Chaque socket avait son propre chemin direct vers la RAM.
Pour les opérateurs, cela se manifestait par quelque chose de palpable :
- Latence mémoire plus faible sous charge — moins d’anomalies de latence tail dans les bases de données et les charges JVM.
- Mise à l’échelle plus prévisible en ajoutant des sockets, parce que la bande passante mémoire évoluait plus linéairement (avec des réserves, à cause de NUMA).
- Meilleure performance « réelle » pour les charges qui semblent modestes en utilisation CPU mais sont en réalité limitées par la mémoire.
Le contrôleur mémoire intégré a aussi forcé un changement culturel : on ne peut plus faire semblant que la mémoire est « uniforme ». Si un thread sur le socket 0
martèle la mémoire attachée au socket 1, ce n’est pas « juste de la RAM ». C’est une pénalité d’accès distante, et ça se voit en latence.
2) HyperTransport : une mise à l’échelle qui ne dépendait pas de la prière
HyperTransport a fourni à Opteron un interconnect point-à-point à haute vitesse. Au lieu de voir tous les CPU se battre sur un bus partagé, les sockets pouvaient
communiquer plus directement, et le trafic de cohérence avait un chemin autre que « crier plus fort sur le FSB ».
Cela a eu de l’importance pour deux problèmes classiques d’entreprise :
- Mise à l’échelle multi-socket sans heurter immédiatement un mur de bus partagé.
- Chemins I/O qui ne s’écroulaient pas sous des charges mixtes (réseau + stockage + pression mémoire) aussi rapidement que dans les designs antérieurs.
3) x86-64 comme stratégie de compatibilité, pas comme un test d’orthodoxie
AMD64 a fonctionné parce qu’il ne demandait pas au monde de jeter son logiciel. C’est la génie discret. Le 64-bit n’était pas vendu comme « une nouvelle religion ».
Il était vendu comme « vos outils existants fonctionnent toujours, et maintenant vous pouvez adresser plus de mémoire sans sacrifier votre week-end ».
Ce n’est pas de la langue de bois marketing. C’est des mathématiques opérationnelles. Les entreprises ne modernisent pas d’un coup. Elles pilotent, valident,
migrent et gardent des plans de retour en arrière. AMD64 correspondait à cette réalité.
4) NUMA devient l’impôt que vous devez déposer
NUMA n’est pas optionnel dans les serveurs multi-socket de l’ère Opteron. Vous le comprenez, ou vous payez des intérêts plus tard. L’accès mémoire local est plus rapide.
L’accès mémoire distant est plus lent. La bande passante n’est pas infinie. La cohérence de cache n’est pas gratuite. Et votre base de données se fiche de votre diapositive vendeur.
Si vous devez retenir une habitude d’Opteron, ce devrait être celle-ci : demandez toujours « Où est la mémoire par rapport au CPU qui fait le travail ? »
AMD64 vs Itanium : le carrefour
Itanium était la voie de la « nouvelle architecture » : une rupture propre, une grosse promesse et une grosse exigence — porter votre logiciel. AMD64 était la voie « continuer » :
étendre x86, garder la compatibilité, atteindre le 64-bit sans détoner votre écosystème.
Si vous gérez des systèmes de production, vous savez comment ce film se termine. La plateforme qui demande le moins de réécriture gagne, à condition que la performance soit suffisante
et que les outils ne soient pas catastrophiques. AMD64 a trouvé ce point d’équilibre.
Il y a aussi un angle fiabilité. Les nouvelles architectures introduisent de nouveaux comportements de compilateur, de nouveaux bords de bibliothèques, de nouveaux falaises de performance,
et de nouveaux bugs « ça marchait sur l’ancienne plateforme ». Une partie est inévitable. Mais multiplier ça sur toute une flotte, c’est se créer une carrière en réponse aux incidents.
Une blague, parce qu’on l’a méritée : Itanium était le genre de « futur » qui arrivait toujours juste après la prochaine fenêtre de maintenance.
NUMA : la fonctionnalité qui payait le loyer et causait des disputes
NUMA est un ami à deux faces. Quand vous alignez le calcul avec la mémoire locale, la performance est splendide. Quand vous ne le faites pas, vous obtenez du jitter qui ressemble
à des bugs applicatifs, mais qui est en réalité le matériel vous rappelant qu’il existe.
Opteron a rendu NUMA grand public dans les salles serveurs x86. Il a forcé développeurs et opérateurs à prendre l’affinité au sérieux : pinning CPU, politique mémoire,
placement des IRQ et distribution des interruptions.
L’astuce n’est pas de « tout tuner ». L’astuce est de tuner une ou deux choses qui limitent réellement : la localité mémoire, les interruptions I/O et le comportement de l’ordonnanceur sous contention.
Une idée paraphrasée utile, parce qu’elle reste vraie : Idée paraphrasée — John Ousterhout : mesurer d’abord ; la plupart des gains de performance et de fiabilité proviennent de corriger le vrai goulot d’étranglement, pas de deviner.
Trois mini-récits d’entreprise depuis le terrain
Mini-récit n°1 : L’incident causé par une mauvaise hypothèse
Une entreprise de taille moyenne faisait tourner un système de facturation sensible à la latence sur des serveurs double-socket. L’équipe a migré d’une ancienne plateforme Xeon
vers des machines Opteron parce que le rapport prix/performance était excellent et le fournisseur promettait une « installation facile ».
La migration s’est bien passée jusqu’à la clôture de fin de mois. Soudain, la latence des API a doublé et la base de données a commencé à enregistrer des blocages intermittents.
L’utilisation CPU restait autour de 40–50%. Les graphiques de stockage semblaient calmes. Tout le monde a accusé l’application.
La mauvaise hypothèse : « La mémoire, c’est la mémoire ; s’il y en a assez, peu importe où elle se trouve. » Sur Opteron, c’était absolument important.
Le processus DB avait des threads sautant entre sockets tandis que ses pages mémoire les plus chaudes étaient allouées majoritairement sur un nœud. Le trafic mémoire distant
a augmenté, la latence a suivi, et la charge est tombée dans une boucle de rétroaction : des requêtes plus lentes tenaient les verrous plus longtemps, augmentant la contention
et le ping-pong de lignes de cache.
La correction n’était pas exotique. Ils ont épinglé les threads workers DB aux cœurs, appliqué une allocation mémoire consciente de NUMA (ou au moins interleaving pour cette charge),
et déplacé les IRQ du NIC hors du nœud occupé. La latence est revenue à la normale et la « régression applicative » a disparu comme si elle n’avait jamais existé.
La leçon : Sur NUMA, « assez de RAM » n’est pas équivalent à « RAM rapide ». Traitez la localité comme une métrique de première classe.
Mini-récit n°2 : L’optimisation qui s’est retournée contre eux
Une autre société exploitait un cluster de virtualisation avec un mélange de charges web et batch. Ils ont découvert que désactiver certaines fonctions de gestion d’énergie rendait les chiffres de benchmark plus flatteurs.
L’équipe a appliqué le changement à toute la flotte : mode performance partout, tout le temps.
Au début, les graphiques semblaient excellents. Latence plus faible. Débit plus élevé. On a célébré la victoire. Puis l’été est arrivé, accompagné d’une série
d’événements de thermal throttling et de pannes de ventilateurs. Le budget de refroidissement du datacenter n’était pas infini et les racks étaient déjà denses.
Sous chaleur soutenue, certains nœuds ont commencé à réduire leur fréquence de façon imprévisible. Cette imprévisibilité a compté davantage que le gain moyen.
L’ordonnanceur de virtualisation a couru après la charge, les VMs ont migré à des moments inopportuns, et le cluster a développé une nouvelle personnalité : parfois rapide, souvent grognon.
Ils sont revenus à une politique équilibrée, n’ont utilisé les réglages de performance par hôte que pour des paliers de latence spécifiques, et ont ajouté des alertes de surveillance thermique
liées aux signaux réels de throttling plutôt qu’à la seule « température ambiante élevée ».
La leçon : une optimisation qui ignore la puissance et la thermique n’est que de la dette technique avec une courbe de ventilateur.
Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une équipe de services financiers exploitait des serveurs Opteron depuis des années. Rien de glamour. Principalement des bases de données et des files de messages. Leur arme secrète
n’était pas un patch noyau exotique ni une séance de tuning héroïque. C’était une discipline de baseline.
Chaque trimestre, ils capturaient un instantané « connu bon » de la télémétrie hardware et OS : disposition NUMA, distribution des IRQ, bande passante mémoire sous un test standard,
latence de stockage sous une charge contrôlée et profil de performance des services principaux. Ils le stockaient avec la même rigueur que les sauvegardes.
Un jour, une mise à jour de firmware a changé silencieusement le comportement d’interleaving mémoire. Le système démarrait toujours. Aucune alarme. Mais leur comparaison baseline a détecté
une augmentation significative des accès mémoire distants et une baisse mesurable de la bande passante mémoire. Avant que les utilisateurs ne le remarquent, ils ont suspendu le déploiement,
ouvert un ticket fournisseur et figé la version du firmware pour cette génération matérielle.
La correction a été simple : ajuster les paramètres du firmware pour retrouver le comportement antérieur et valider avec les mêmes tests de baseline. Pas d’incident.
Pas de war room. Juste un ticket ennuyeux et un journal de modifications propre.
La leçon : les pratiques ennuyeuses battent les héroïques excitantes. Les baselines transforment les « régressions mystérieuses » en « deltas connus ».
Mode d’emploi pour un diagnostic rapide : trouver le goulot rapidement
Voici l’ordre que j’utilise quand un serveur « paraît lent » et que la responsabilité est balancée comme une patate chaude. Il est ajusté pour les réalités de l’ère Opteron
(NUMA, contrôleurs mémoire par socket, mise à l’échelle multi-socket), mais il s’applique encore aux systèmes modernes.
Première étape : confirmer quel type de lenteur vous avez
- Pics de latence ? Cherchez des retards d’ordonnancement, mémoire distante, contention de verrous, tempêtes d’IRQ.
- Chute de débit ? Cherchez saturation de bande passante mémoire, profondeur de file I/O, throttling ou un cœur surchargé.
- Seulement en concurrence ? Suspectez placement NUMA, rebond de lignes de cache ou contention de ressources partagées.
Deuxième étape : CPU vs mémoire vs I/O en 10 minutes
- Pression d’ordonnancement CPU : exécutez
vmstat 1et vérifiez la file d’exécution, les changements de contexte et le steal time. - Localité mémoire : vérifiez les stats NUMA avec
numastatet la topologie CPU/nœud aveclscpu. - Attente et latence I/O : exécutez
iostat -x 1et regardezawait,svctm(si présent) et l’utilisation. - Réseau : vérifiez les drops et overruns avec
ip -s linket la distribution des interruptions.
Troisième étape : valider le graphique « évident » avec un outil de vérité terrain
- Compteurs perf :
perf statetperf toppour CPI, défauts de cache et fonctions chaudes. - Vue noyau :
pidstat,sar,dmesgpour throttling et plaintes de drivers. - Placement :
taskset,numactl,/proc/interruptspour voir si vous avez accidentellement créé une taxe inter-socket.
Tâches pratiques : commandes, sens de la sortie et décision à prendre
Voici les vérifications que j’exécute réellement. Chaque tâche inclut : une commande exécutable, un exemple de sortie, ce que cela signifie et la décision qui s’ensuit.
Supposez Linux sur bare metal ou une VM avec suffisamment de visibilité.
Tâche 1 : Identifier le modèle CPU et la topologie des cœurs
cr0x@server:~$ lscpu
Architecture: x86_64
CPU(s): 16
Thread(s) per core: 1
Core(s) per socket: 8
Socket(s): 2
NUMA node(s): 2
Vendor ID: AuthenticAMD
Model name: AMD Opteron(tm) Processor 285
NUMA node0 CPU(s): 0-7
NUMA node1 CPU(s): 8-15
Sens : Deux sockets, deux nœuds NUMA. Tout ordonnancement « aléatoire » peut créer des accès mémoire distants.
Décision : Pour les services sensibles à la latence, planifiez le pinning CPU ou un déploiement conscient NUMA (une instance par socket, si possible).
Tâche 2 : Confirmer les distances NUMA (à quel point le « distant » coûte cher)
cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 16384 MB
node 0 free: 12210 MB
node 1 cpus: 8 9 10 11 12 13 14 15
node 1 size: 16384 MB
node 1 free: 12044 MB
node distances:
node 0 1
0 10 20
1 20 10
Sens : L’accès à un nœud distant coûte ~2× en distance relative. Ce n’est pas subtil.
Décision : Si vous voyez beaucoup de trafic distant plus tard, traitez-le comme une cause d’incident de première classe, pas comme du « bruit ».
Tâche 3 : Vérifier si le noyau utilise NUMA balancing (et si cela doit vous préoccuper)
cr0x@server:~$ sysctl kernel.numa_balancing
kernel.numa_balancing = 1
Sens : L’équilibrage NUMA automatique est activé. Ça peut aider, ou générer du churn de migration de pages.
Décision : Pour des charges stables de bases de données, testez en staging avec ça activé/désactivé. Si vous observez des migrations et du jitter, envisagez de désactiver et d’épingler.
Tâche 4 : Repérer rapidement la pression sur la run-queue et l’activité de swap
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 122100 81200 945000 0 0 1 5 310 540 18 4 76 2 0
8 0 0 121880 81200 945120 0 0 0 0 900 1800 55 10 33 2 0
9 0 0 121700 81200 945200 0 0 0 16 920 1900 58 12 28 2 0
3 1 0 121500 81200 945210 0 0 120 0 600 1200 20 6 68 6 0
2 0 0 121480 81200 945240 0 0 0 0 330 560 16 4 78 2 0
Sens : La colonne r montant en flèche (8–9) indique des tâches exécutables dépassant la capacité CPU. wa est bas, le swap est nul.
Décision : C’est de la pression d’ordonnancement CPU, pas du disque. Cherchez les threads chauds, l’affinité ou la contention de verrous.
Tâche 5 : Identifier si vous êtes CPU-bound ou memory-bound (rapide et sale)
cr0x@server:~$ perf stat -a -- sleep 5
Performance counter stats for 'system wide':
18,245.12 msec task-clock # 3.649 CPUs utilized
12,345,678,901 cycles # 0.677 GHz
9,876,543,210 instructions # 0.80 insn per cycle
1,234,567,890 cache-references
456,789,012 cache-misses # 36.99% of all cache refs
5.001234567 seconds time elapsed
Sens : Un IPC autour de 0.8 et un taux élevé de cache miss suggèrent des stalls — souvent latence/bande passante mémoire, pas du pur calcul.
Décision : Vérifiez la localité NUMA et la pression sur la bande passante mémoire avant d’acheter « plus de CPU ».
Tâche 6 : Vérifier allocations mémoire locales vs distantes par processus (vérif NUMA)
cr0x@server:~$ numastat -p 1234
Per-node process memory usage (in MBs) for PID 1234 (postgres)
Node 0 Node 1 Total
Private 8200 900 9100
Heap 600 4200 4800
Stack 20 18 38
Huge 0 0 0
Total 8820 5118 13938
Sens : La mémoire est répartie de façon inégale ; si les threads CPU sont majoritairement sur le nœud 0 mais que le heap est lourd sur le nœud 1, attendez-vous à des pénalités distantes.
Décision : Épinglez le processus ou utilisez des politiques numactl ; envisagez d’exécuter une instance par socket pour une localité prévisible.
Tâche 7 : Inspecter l’affinité CPU d’un processus (laissez-vous le scheduler se goinfrer ?)
cr0x@server:~$ taskset -pc 1234
pid 1234's current affinity list: 0-15
Sens : Le processus peut s’exécuter n’importe où, augmentant les risques de rebond inter-nœud.
Décision : Pour les services à latence tail, restreignez au nœud NUMA (par ex. CPUs 0–7) et gardez la mémoire locale.
Tâche 8 : Vérifier la latence des périphériques de stockage et le comportement des files
cr0x@server:~$ iostat -x 1 3
Device r/s w/s rkB/s wkB/s await svctm %util
sda 45.0 12.0 820.0 140.0 4.20 0.90 52.0
md0 0.0 0.0 0.0 0.0 0.00 0.00 0.0
nvme0n1 500.0 300.0 64000.0 32000.0 0.45 0.10 78.0
Sens : await est la latence vue par les requêtes. Un %util élevé avec await croissant pointe vers la saturation.
Décision : Si await monte sous charge, réduisez les I/O aléatoires, augmentez le cache ou déplacez les données chaudes — ne blâmez pas le CPU à tort.
Tâche 9 : Vérifier les symptômes de latence au niveau du système de fichiers (bloqué sur des écritures ?)
cr0x@server:~$ pidstat -d 1 3 -p 1234
Linux 5.15.0 (server) 01/09/2026 _x86_64_ (16 CPU)
12:00:01 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
12:00:02 PM 1001 1234 0.00 4200.00 0.00 18 postgres
12:00:03 PM 1001 1234 0.00 3900.00 0.00 22 postgres
12:00:04 PM 1001 1234 0.00 4100.00 0.00 20 postgres
Sens : L’augmentation de iodelay indique du temps bloqué sur I/O (comptabilité du noyau). C’est une preuve accablante quand le CPU semble inactif.
Décision : Examinez l’amplification d’écriture, la fréquence fsync, le cache RAID ou la saturation du backend stockage.
Tâche 10 : Vérifier les pertes et erreurs réseau (parce que « CPU correct » peut quand même être réseau)
cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
987654321 1234567 0 842 0 0
TX: bytes packets errors dropped carrier collsns
876543210 1122334 0 9 0 0
Sens : Les drops RX (842) ne sont pas « cosmétiques ». Ils peuvent déclencher des retransmissions et des pics de latence.
Décision : Vérifiez les buffers d’anneau, l’affinité IRQ et la congestion ; envisagez d’ajuster le RSS selon le NIC.
Tâche 11 : Inspecter la distribution des interruptions (mode d’échec classique multi-socket)
cr0x@server:~$ cat /proc/interrupts | head -n 12
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
24: 9876543 0 0 0 0 0 0 0 IO-APIC 24-fasteoi eth0
25: 1200 1100 1150 1080 1120 1090 1110 1070 IO-APIC 25-fasteoi nvme0q0
NMI: 120 118 121 119 117 120 122 118 Non-maskable interrupts
Sens : Les interruptions d’eth0 sont épinglées uniquement sur CPU0. Cela peut goulotter le réseau et voler des cycles au mauvais endroit.
Décision : Rééquilibrez les IRQ (irqbalance ou smp_affinity manuel) et gardez les interruptions NIC sur le même nœud NUMA que la charge.
Tâche 12 : Détecter la réduction de fréquence CPU / problèmes thermiques
cr0x@server:~$ dmesg -T | egrep -i "thrott|thermal|clock"
[Thu Jan 9 11:58:12 2026] CPU0: Core temperature above threshold, cpu clock throttled
[Thu Jan 9 11:58:15 2026] CPU0: Core temperature/speed normal
Sens : Le CPU se protège. Vos « pics de latence aléatoires » peuvent être de la physique, pas du logiciel.
Décision : Réglez le flux d’air, les courbes de ventilateur, les dissipateurs ou la politique d’alimentation ; ne tunez pas l’app pour compenser une machine chaude.
Tâche 13 : Confirmer l’utilisation des huge pages (bon serviteur, mauvais maître)
cr0x@server:~$ grep -i huge /proc/meminfo
AnonHugePages: 1048576 kB
HugePages_Total: 2048
HugePages_Free: 512
HugePages_Rsvd: 128
Hugepagesize: 2048 kB
Sens : Les huge pages sont en jeu. Cela peut améliorer le comportement du TLB mais compliquer l’allocation mémoire et la placement NUMA.
Décision : Si des échecs d’allocation ou un usage inégal des nœuds apparaissent, ajustez la réservation de huge pages par nœud NUMA ou revenez en arrière pour cette charge.
Tâche 14 : Vérifier la pression sur la bande passante mémoire (proxy pratique)
cr0x@server:~$ sar -B 1 3
Linux 5.15.0 (server) 01/09/2026 _x86_64_ (16 CPU)
12:01:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
12:01:02 PM 0.00 850.00 22000.00 0.00 48000.00 0.00 0.00 0.00 0.00
12:01:03 PM 0.00 920.00 24000.00 0.00 49000.00 0.00 0.00 0.00 0.00
12:01:04 PM 0.00 870.00 23000.00 0.00 47500.00 0.00 0.00 0.00 0.00
Sens : Beaucoup de page faults (mineurs) sans faults majeurs suggèrent un churn mémoire mais pas nécessairement du paging disque. Cela peut corréler avec une
contrainte de bande passante mémoire.
Décision : Si la latence corrèle avec des pics ici, profilez les allocations, réduisez le churn et validez la localité NUMA — particulièrement pour les JVM et caches DB.
Deuxième blague, parce qu’on en a tous besoin : NUMA, c’est comme le placement au bureau — mettez l’équipe près du tableau blanc, ou profitez de longues réunions sur la « latence de communication ».
Erreurs courantes : symptômes → cause racine → correctif
1) Symptom : Le CPU n’est « pas élevé », mais la latence est catastrophique
Cause racine : Stalls mémoire (accès NUMA distant, défauts de cache) ou contention de verrous ; l’utilisation CPU ment par omission.
Fix : Utilisez perf stat pour IPC/défauts, numastat pour la localité, puis épinglez les threads et appliquez des politiques mémoire NUMA.
2) Symptom : Ajouter un second socket n’a pas augmenté le débit
Cause racine : La charge est mono-thread, sérialisée sur un verrou, ou limitée par la bande passante mémoire d’un nœud NUMA.
Fix : Profilez les hotspots ; scindez en plusieurs processus indépendants épinglés par socket ; assurez-vous que les allocations mémoire sont locales par instance.
3) Symptom : Le débit réseau plafonne en dessous du débit du lien et des drops apparaissent
Cause racine : IRQ épinglées sur un seul cœur, mauvaise configuration RSS, ou drivers aux paramètres par défaut inadaptés aux charges PPS élevées.
Fix : Distribuez les IRQ sur des cœurs du bon nœud NUMA ; validez avec /proc/interrupts et les compteurs de drops.
4) Symptom : Pics de latence stockage pendant des jobs « CPU-heavy »
Cause racine : Interruptions de complétion I/O et contention ksoftirqd ; le chemin stockage concurrence le calcul sur les mêmes cœurs.
Fix : Séparez les cœurs d’IRQ ; isolez des CPUs pour les paliers de latence ; confirmez avec pidstat -d et iostat -x.
5) Symptom : Ralentissements aléatoires après des changements firmware/BIOS
Cause racine : Interleaving mémoire, C-states ou politique d’alimentation modifiés ; le comportement NUMA a changé subtilement.
Fix : Comparez les baselines (distances NUMA, tests de bande passante mémoire, compteurs perf). Restaurez ou standardisez les paramètres sur toute la flotte.
6) Symptom : L’hôte de virtualisation est instable, les VMs migrent « trop »
Cause racine : Surcommit + placement non conscient NUMA ; les VMs couvrent plusieurs nœuds et subissent des pénalités mémoire distantes.
Fix : Gardez vCPU et mémoire d’une VM dans un nœud quand c’est possible ; utilisez des pools par nœud NUMA ; validez avec métriques hôte et invité.
Listes de contrôle / plan étape par étape
Checklist A : Lors de l’achat ou de la reprise de serveurs de l’ère Opteron (ou de toute machine NUMA)
- Confirmez sockets/nœuds NUMA avec
lscpuetnumactl --hardware. - Standardisez les paramètres BIOS : politique d’interleaving mémoire, politique d’alimentation, paramètres de virtualisation et options d’interconnexion de nœuds.
- Établissez une baseline :
perf statà l’arrêt et sous une charge contrôlée, plusiostat -xetip -s link. - Documentez la distribution des IRQ sur un hôte connu-bon (capture de
/proc/interrupts). - Choisissez une stratégie NUMA par workload : « épingler par socket », « interleave mémoire » ou « laisser l’équilibrage faire » (seulement après test).
Checklist B : Quand un service ralentit après migration vers un nouveau matériel
- Confirmez horloges/throttling avec
dmesget les outils de fréquence CPU (si disponibles). - Vérifiez la file d’exécution et l’attente I/O :
vmstat 1, puisiostat -x 1. - Validez la localité NUMA :
numastat -ppour le processus et affinité CPU avectaskset -pc. - Vérifiez les hotspots IRQ :
cat /proc/interrupts, puis corrélez avec les drops réseau/stockage. - Ce n’est qu’ensuite que vous tunez l’application — car un mauvais placement hardware peut imiter une régression logicielle à la perfection.
Checklist C : Un plan de tuning sensé (ne vous tunez pas dans un coin)
- Mesurez : capturez 10 minutes de
vmstat,iostatetperf statautour du problème. - Faites un changement à la fois (pinning, affinité IRQ, politique mémoire), puis remesurez.
- Privilégiez les changements réversibles (overrides systemd, wrappers de service) plutôt que la « soupe de sysctl » mystère.
- Notez la justification. Le vous du futur est une personne différente et moins patiente.
FAQ
1) L’avantage principal d’Opteron était-il juste le « 64-bit » ?
Non. Le 64-bit comptait, mais le design système d’Opteron — contrôleur mémoire intégré et meilleur interconnect multi-socket — a apporté des performances tangibles
et une prévisibilité pour les charges réelles.
2) Pourquoi les contrôleurs mémoire intégrés ont-ils autant changé la performance serveur ?
Ils ont réduit la latence mémoire et supprimé un goulot partagé (northbridge/FSB). Pour les bases de données, le middleware et les hôtes de virtualisation,
le comportement mémoire domine souvent la perception de performance.
3) Quel est le mode d’échec opérationnel le plus courant de l’ère Opteron ?
L’ignorance de NUMA : des charges tournant sur un socket alors que la mémoire est allouée sur un autre, produisant des pénalités d’accès distant et un jitter qui ressemble
à une « lenteur aléatoire ».
4) Dois-je toujours épingler les processus à un nœud NUMA ?
Pas toujours. Le pinning peut aider les charges stables et sensibles à la latence. Il peut nuire aux charges rafales ou très mixtes si vous les contraignez accidentellement.
Testez avec une charge proche de la production et surveillez la latence tail, pas seulement les moyennes.
5) Comment savoir si je suis memory-bound sans outils sophistiqués ?
Recherchez un IPC bas dans perf stat, des taux élevés de cache miss et des symptômes où l’utilisation CPU n’est pas élevée mais le débit n’augmente pas.
Validez ensuite la localité NUMA avec numastat.
6) Pourquoi AMD64 a-t-il battu Itanium sur le marché ?
La compatibilité. AMD64 a permis aux entreprises de passer au 64-bit sans tout réécrire. Itanium demandait des ports et introduisait des frictions d’écosystème.
En entreprise, la friction coûte cher.
7) Est-ce que tout ceci importe encore sur les CPU modernes ?
Oui. Les plateformes modernes ont toujours NUMA, plusieurs canaux mémoire, des interconnects complexes et des problèmes de localité IRQ/CPU. Les étiquettes ont changé.
La physique n’a pas changé.
8) Quel est le contrôle le plus rapide « CPU ou I/O ? »
vmstat 1 plus iostat -x 1. Si wa et await montent, suspectez le stockage. Si la file d’exécution monte et wa est faible,
suspectez l’ordonnancement CPU, des verrous ou des stalls mémoire.
9) La virtualisation peut-elle masquer les problèmes NUMA ?
Elle peut masquer la cause tout en amplifiant les symptômes. Si une VM couvre des nœuds, l’accès mémoire distant devient un « jitter mystérieux ». Privilégiez un dimensionnement
et un placement VM alignés NUMA.
Conclusion : prochaines étapes que vous pouvez réellement faire
Opteron a ouvert la porte VIP pour AMD en résolvant les problèmes que les opérateurs étaient déjà payés pour résoudre : mise à l’échelle, comportement mémoire,
compatibilité et performance prévisible sous charge. La leçon n’est pas de la nostalgie. La leçon est l’alphabétisation architecturale : si vous ne comprenez pas
où se trouve le goulot, vous optimiserez avec assurance la mauvaise chose.
Prochaines étapes :
- Sur un hôte de type production, capturez une baseline :
lscpu,numactl --hardware,vmstat,iostat -x,ip -s link,/proc/interrupts. - Choisissez un service critique et validez la localité NUMA avec
numastat -pet l’affinité CPU avectaskset. - Corrigez le plus gros désajustement en premier (généralement la distribution IRQ ou la localité mémoire), puis remesurez. Si les graphiques ne bougent pas, vous n’avez pas corrigé le goulot.
- Notez ce à quoi ressemble le « bon » pour cette génération matérielle. Le jour où vous en aurez besoin, vous n’aurez pas le temps de le recréer.