Athlon : l’année où Intel a vraiment eu peur

Ce qui a fait d’Athlon une menace (pas seulement un concurrent)

Athlon n’était pas « AMD a enfin rattrapé son retard ». C’était AMD choisissant les bons combats : performance par cycle, bande passante mémoire,
et une histoire de plateforme qui ne donnait pas l’impression de s’excuser. À la fin des années 1990 et au début des années 2000, la marque
Intel était la case par défaut des bons de commande. Athlon a montré que cette case pouvait être erronée.

Le but n’est pas la nostalgie. Le but est la pensée systémique. L’avantage d’Athlon n’était pas un transistor magique ; c’était
un ensemble de choix architecturaux qui réduisaient l’attente. Les CPU ne « calculent » pas la plupart du temps — ils attendent des données, attendent
des branches, attendent des bus, attendent que les caches se remplissent. Votre pile de production n’est pas différente. Vos microservices
sont juste des CPU avec de pires prédicteurs de branchement.

La performance n’est pas la fréquence ; c’est le temps vers un travail utile

Intel et AMD ont tous deux livré du silicium rapide. Mais Athlon transformait souvent sa capacité théorique en débit livré plus efficacement — surtout
dans les types de charges mixtes que les gens utilisaient réellement : jeux, compilations, applications workstation, et premières tâches serveurs sensibles au comportement mémoire.

Voici le parallèle opérationnel : vous pouvez acheter une classe d’instance plus grande et rester lié par une file saturée unique. Pour Athlon, réduire « l’attente sur le reste de la plateforme » faisait partie du design. Pour vous, c’est la différence entre une montée en CPU et une vraie amélioration de latence.

L’histoire du bus et du cache (la partie que les marketeurs détestent)

L’écosystème Athlon a forcé beaucoup de monde à remarquer la plateforme comme un système : cœur CPU, hiérarchie de caches,
placement du cache externe (précoce), sous-système mémoire, qualité du chipset, et — de manière critique — comment tout cela interagit sous charge.
Si vous avez déjà vu une mise à niveau 2× CPU produire une amélioration de 0 % parce que votre base de données attend le stockage, vous avez déjà vécu la leçon.

Blague #1 : La seule chose plus optimiste qu’un benchmark est l’ingénieur qui l’a lancé sur un système inactif.

Faits rapides et contexte historique

Points concrets qui comptent parce qu’ils ont façonné les décisions de conception et le comportement concurrentiel :

1. Athlon lancé en 1999 et est rapidement devenu un prétendant crédible au titre de « x86 le plus rapide » dans la perception grand public, pas seulement dans des cercles de niche.
2. Slot A ressemblait au Slot 1 d’Intel mais n’était pas électriquement compatible — une ligne volontaire tracée dans la plateforme.
3. Les premiers Athlon utilisaient un cache L2 externe situé sur la cartouche ; plus tard « Thunderbird » a apporté le L2 sur puce, réduisant la latence et améliorant le débit effectif.
4. Héritage du bus EV6 (dérivé des designs DEC Alpha) a donné à Athlon une histoire de plateforme axée sur la bande passante et la montée en charge qui semblait moderne pour l’époque.
5. « Thunderbird » (2000) a rendu Athlon non seulement compétitif mais souvent dominant en termes de prix/performance pour les charges grand public.
6. L’ère Pentium III d’Intel avait une forte performance par cycle, mais l’histoire de la plateforme et la pression sur la feuille de route étaient réelles ; le marché était moins unilatéral que le sticker « Intel Inside » ne le laissait croire.
7. Les guerres de marque ont compté : le système de nommage « Performance Rating » (PR) d’AMD reflétait plus tard le besoin de l’industrie de s’affranchir des comparaisons brutes en MHz.
8. Thermique et consommation sont devenues stratégiques à mesure que les fréquences augmentaient ; cette époque a contribué à préparer le pivot industriel ultérieur loin du « GHz à tout prix ».
9. Les chipsets étaient une surface de risque : la maturité des chipsets tiers pouvait faire ou défaire la stabilité en conditions réelles, annonçant la chaîne de fiabilité « matériel + firmware + pilote » d’aujourd’hui.

Où Intel a vraiment fléchi

« Intel a eu peur » ne signifie pas panique dans les couloirs. Cela signifie pression sur la feuille de route. Cela signifie des changements de posture marketing.
Cela signifie des mouvements de prix. Cela signifie des équipes internes sommées d’arrêter de supposer qu’elles gagnent par défaut.
En termes opérationnels : vous n’avez pas besoin d’une panne pour savoir que vous êtes en difficulté ; vous avez besoin que votre graphe de budget d’erreur cesse d’être théorique.

La partie inconfortable : Athlon a rendu le choix par défaut discutable

Les grands vendeurs prospèrent sur l’inertie. L’avantage d’Intel n’était pas seulement l’ingénierie ; c’était le confort d’approvisionnement.
Quand Athlon était fort, « personne ne s’est jamais fait renvoyer pour avoir acheté Intel » est devenu moins vrai — parce que des gens ont commencé
à se faire renvoyer pour avoir acheté l’option la plus chère qui ne délivrait pas une meilleure performance par dollar.

Un concurrent qui force la prise de décision est dangereux. Il déclenche des revues : « Payons-nous trop ? Notre feuille de route est-elle trop optimiste ? Benchmarquons-nous la bonne chose ? »
C’est la peur en forme corporative : pas de la terreur, mais de l’examen minutieux.

La leçon d’Intel (et la vôtre) : les feuilles de route ne sont réelles que si la physique est d’accord

Cette période rappelle que les contraintes d’ingénierie finissent par faire payer leur dette. Vous pouvez vendre votre message pour un trimestre.
Vous ne pouvez pas expliquer la latence mémoire ou la densité de puissance indéfiniment.
Le succès d’Athlon n’a pas seulement volé des ventes ; il a resserré le calendrier de la réalité pour Intel.

Exigence de citation (idée paraphrasée) : L’idée de John Ousterhout : ne devinez pas la performance — mesurez-la, car l’intuition se trompe systématiquement dans les systèmes réels. — John Ousterhout (paraphrasé)

Blague #2 : Si votre feuille de route dépend de « et ensuite le cache sera rapide », ce n’est pas un plan ; c’est une histoire pour la nuit.

Leçons d’architecture que les SRE doivent reprendre

1) Les goulots bougent ; ils ne disparaissent pas

Athlon n’a pas éliminé les contraintes. Il les a déplacées. Intégrer le cache sur la puce réduit une classe de latence et en expose une autre. En production, c’est le classique « on a optimisé le CPU et maintenant le réseau est le problème. »
La victoire n’est pas « pas de goulots ». La victoire est « des goulots vivables » et « des goulots que l’on peut scaler ».

2) La qualité de la plateforme compte autant que la vitesse CPU maximale

Quiconque a subi des chipsets instables, des BIOS immatures ou des pilotes bizarres a appris à la dure qu’un CPU rapide greffé sur une plateforme douteuse est une grenade de fiabilité.
Aujourd’hui c’est pareil avec les instances cloud : la VM est rapide ; le chemin de stockage du voisin bruyant ne l’est pas. Mesurez toute la chaîne.

3) La latence est une caractéristique produit même si vous ne la vendez pas

Les utilisateurs n’achètent pas la « latence de cache plus faible ». Ils achètent « c’est réactif » et « ça ne saccade pas ».
Vos clients n’achètent pas « p99 amélioré de 30 % ». Ils achètent « le paiement fonctionne » et « la recherche ne se fige pas ».
L’avantage d’Athlon dans de nombreuses charges était de fournir une meilleure réactivité réelle — pas seulement un coup de coude sur la fiche technique.

4) Les benchmarks sont des outils, pas des verdicts

L’ère Athlon a été pleine de théâtre de benchmark, alors comme maintenant. Compilateurs optimisés par le vendeur. Charges choisies.
Tests « représentatifs » qui, mystérieusement, ressemblaient au chemin de code préféré du sponsor.
Votre version de ceci est le test de charge synthétique qui n’inclut pas le warmup du cache, la poignée de main TLS, ou le cron qui s’exécute à minuit et met votre file en feu.

5) La pression concurrentielle améliore la discipline opérationnelle

Un monopole engendre la désinvolture. La concurrence force la mesure, la discipline des coûts et une meilleure ingénierie.
Il en va de même à l’intérieur d’une entreprise : si votre équipe n’est jamais auditée, vos hypothèses se calcifient. Si vous devez défendre votre modèle de capacité auprès des finances, vous vous souvenez soudain comment mesurer la réalité.

Manuel de diagnostic rapide : trouver le goulot avant la réunion

C’est la séquence « arrivez sans préparation, repartez crédible ». Utilisez-la quand la latence augmente, le débit diminue,
ou que le nouveau matériel « devrait être plus rapide » mais ne l’est pas. L’objectif n’est pas la perfection ; c’est identifier rapidement le sous-système limitant et éviter de perdre une journée à débattre des impressions.

D’abord : le système est-il CPU-bound ou waiting-bound ?

• Vérifiez la moyenne de charge versus l’utilisation CPU (une charge élevée avec peu de CPU souvent signifie attente I/O).
• Regardez la file d’exécution, les commutations de contexte et l’iowait.
• Décidez : poursuivez-vous des cycles CPU, de la contention de verrou, ou des dépendances externes ?

Second : si le CPU est chaud, fait-il un travail utile ?

• Identifiez les processus et threads en tête.
• Vérifiez un temps sys excessif, les interruptions et softirqs (tempêtes réseau, interruptions de stockage).
• Décidez : tunez l’app, tunez le kernel/réseau, ou réduisez la pression d’interruption.

Troisième : si c’est de l’attente, quelle file se remplit ?

• Disque : latence (await), utilisation, profondeur de file.
• Réseau : retransmissions, pertes, files de sockets.
• Mémoire : swapping, fautes majeures, thrash du cache de pages.
• Décidez : scalez, repartitionnez, corrigez la configuration, ou changez le placement de la charge.

Quatrième : confirmez avec une trace unique « vérité terrain »

• Un échantillon perf court, une trace eBPF, ou une capture des requêtes lentes de la base.
• Décidez : livrez un correctif, revenez en arrière, ou appliquez une mitigation chirurgicale.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Ce ne sont pas des commandes « mignonnes ». Ce sont celles que vous lancez quand vous êtes responsable de la disponibilité et que le CFO est responsable de votre budget. Chaque tâche inclut : commande, ce que signifie la sortie, et la décision que vous prenez.

Task 1: Identify CPU saturation vs waiting

cr0x@server:~$ uptime
 14:22:10 up 32 days,  3:11,  2 users,  load average: 18.42, 17.90, 16.55

Signification : Une moyenne de charge ~18 sur une machine qui pourrait avoir, disons, 8 vCPU est suspecte. La charge compte les tâches exécutables et en sommeil ininterruptible.
Si l’utilisation CPU n’est pas corrélée, c’est souvent de l’attente I/O ou des verrous.
Décision : Ne pas monter de CPU immédiatement. Vérifiez iowait et la file d’exécution ensuite.

Task 2: Confirm iowait, run queue, and steal time

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server)  01/09/2026  _x86_64_  (16 CPU)

14:22:12     CPU   %usr   %nice    %sys %iowait   %irq  %soft  %steal  %idle
14:22:13     all   22.10    0.00    6.45   38.90   0.10   1.25    0.00  31.20
14:22:13       0   25.00    0.00    7.00   41.00   0.00   1.00    0.00  26.00

Signification : iowait ~39% signifie que les CPU sont inactifs car ils attendent la complétion d’I/O.
Décision : Allez aux métriques du chemin de stockage (iostat, nvme, mdraid, système de fichiers). Les upgrades CPU n’aideront pas.

Task 3: Check per-disk latency and queueing

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (server)  01/09/2026  _x86_64_  (16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  avgqu-sz  await  r_await  w_await  %util
nvme0n1         120.0   450.0   8400   51200      9.20   18.4     4.2     22.1   96.0
nvme1n1         110.0   430.0   8000   49800      8.70   17.9     4.0     21.6   94.5

Signification : %util ~95% et avgqu-sz ~9 indiquent que les périphériques NVMe sont proches de la saturation ; await ~18ms est élevé pour du NVMe sous charge continue.
Décision : Réduire l’amplification d’écriture (réglages DB), déplacer les données chaudes, ajouter des périphériques, ou corriger la disposition du système de fichiers/RAID.

Task 4: Identify top offenders at the process level

cr0x@server:~$ pidstat -d 1 3
Linux 6.5.0 (server)  01/09/2026  _x86_64_  (16 CPU)

14:22:20      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
14:22:21     1001     18422      80.00  22000.00  15000.00 postgres
14:22:21        0      1432       0.00   1800.00      0.00  journald

Signification : Postgres génère de lourdes écritures, et beaucoup sont des « cancelled writes » (comportement d’écriture différée du cache), souvent lié aux patterns fsync.
Décision : Inspecter les checkpoints DB, les réglages WAL, et les options de montage du système de fichiers ; envisager de séparer le WAL sur un périphérique dédié.

Task 5: Spot memory pressure and swapping (the silent latency 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
 6  4  262144  12000  32000 1800000  0   64   120  8400 4200 9800 18  6 33 43  0

Signification : Un swap out non nul (so) indique que le noyau pousse des pages vers le swap sous pression. Combiné à un wa élevé (iowait), vous aggravez la douleur.
Décision : Réduire l’empreinte mémoire, ajuster les limites cgroup, ajouter de la RAM, ou isoler les jobs gourmands en mémoire loin des services sensibles à la latence.

Task 6: Confirm filesystem and mount options (sync traps)

cr0x@server:~$ mount | grep ' /var/lib/postgresql '
/dev/nvme0n1p2 on /var/lib/postgresql type ext4 (rw,relatime,data=ordered)

Signification : ext4 data=ordered est normal, mais les patterns de charge (fsync intensif) peuvent toujours nuire. Vérifiez aussi les barrières, discard, et le comportement du journal selon le périphérique.
Décision : Si la latence est instable, envisagez de séparer le WAL, d’ajuster le checkpointing, ou d’utiliser des systèmes de fichiers/périphériques alignés sur votre profil d’écriture.

Task 7: Check NVMe health and error counters

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 44 C
available_spare                     : 100%
percentage_used                     : 72%
media_errors                        : 0
num_err_log_entries                 : 3

Signification : percentage_used à 72% suggère que le disque est bien entamé ; des entrées dans le journal d’erreurs existent même si media_errors est 0.
Décision : Planifier le remplacement avant que cela ne devienne un incident de fiabilité ; valider le firmware et vérifier les journaux d’erreurs pour des motifs.

Task 8: Find CPU hotspots when CPU is actually the limit

cr0x@server:~$ sudo perf top -g --call-graph dwarf
Samples: 2K of event 'cpu-clock:pppH', 4000 Hz, Event count (approx.): 500000000
  18.40%  postgres  libc.so.6          [.] __memcmp_avx2_movbe
  11.10%  postgres  postgres           [.] hash_search_with_hash_value
   7.25%  postgres  postgres           [.] ExecHashJoin

Signification : CPU chaud sur les chemins de hash join / hashing suggère des problèmes de forme de requête ou des index manquants ; memcmp chaud peut indiquer de grandes comparaisons ou un comportement de collation.
Décision : Changer les plans de requête (index), réduire la pression des hash joins, tuner work_mem, ou ajuster le schéma. Acheter du CPU ne corrigera pas une requête pathologique.

Task 9: Diagnose lock contention (the “CPU upgrade did nothing” classic)

cr0x@server:~$ pidstat -w 1 3
Linux 6.5.0 (server)  01/09/2026  _x86_64_  (16 CPU)

14:23:10      UID       PID   cswch/s nvcswch/s  Command
14:23:11     1001     18422   1200.00  8400.00   postgres

Signification : Des commutations de contexte non volontaires très élevées (nvcswch/s) signifient souvent que des threads sont forcés hors CPU — locks, attentes I/O, préemption.
Décision : Corréler avec les verrous DB, les stats du scheduler kernel, et l’I/O. Si ce sont des verrous, corrigez la stratégie de concurrence, pas la fréquence.

Task 10: Network retransmits and drops (the invisible latency)

cr0x@server:~$ ss -s
Total: 4128 (kernel 0)
TCP:   2987 (estab 1842, closed 1010, orphaned 0, timewait 680)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       23        19        4
TCP       1977      1860      117
INET      2000      1879      121
FRAG      0         0         0

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed   mcast
    981G  1183M   0       4212     0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    1044G 1201M   0       0       0       0

Signification : Des paquets RX perdus peuvent provoquer des retransmissions, des pics de latence de queue et des timeouts applicatifs qui ressemblent à « le CPU est lent ».
Décision : Vérifiez les anneaux NIC, la coalescence d’interruptions, les incompatibilités MTU, et la congestion en amont ; envisagez le tuning RSS/affinité IRQ.

Task 11: Confirm NUMA topology and whether you’re cross-socket thrashing

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 64280 MB
node 0 free: 4100 MB
node 1 cpus: 8 9 10 11 12 13 14 15
node 1 size: 64280 MB
node 1 free: 3800 MB

Signification : Deux nœuds NUMA. Si votre processus fait transiter la mémoire entre nœuds, vous payez la latence.
Décision : Pinner les services critiques à un nœud NUMA (CPU + mémoire) ou utiliser des cpusets cgroup pour réduire les pénalités cross-node.

Task 12: Inspect interrupt distribution (IRQ storms hurt “fast CPUs”)

cr0x@server:~$ cat /proc/interrupts | head
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  24:    182392     192301     188210     190102          0          0          0          0  IR-PCI-MSI 524288-edge      nvme0q0
  25:         0          0          0          0     210334     220991     215002     219114  IR-PCI-MSI 524289-edge      nvme0q1

Signification : Les files sont réparties entre ensembles CPU, ce qui est bon. Si vous voyez toutes les interruptions épinglées sur un seul CPU, ce CPU devient votre goulot « Athlon vs Pentium » : un cœur saturé rendant la machine entière lente.
Décision : Corriger l’affinité IRQ ou activer RSS/multiqueue approprié ; puis re-mesurer la latence p99.

Task 13: Verify storage stack (RAID/LVM) isn’t the hidden queue

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT
NAME        TYPE  SIZE FSTYPE MOUNTPOINT
nvme0n1     disk  1.8T
├─nvme0n1p1 part  512M vfat   /boot/efi
└─nvme0n1p2 part  1.8T ext4   /var/lib/postgresql
nvme1n1     disk  1.8T

Signification : Pas de RAID/LVM ici — disposition simple. Si vous voyez mdraid/LVM, confirmez la taille de stripe, les réglages de file et le comportement du cache d’écriture.
Décision : Gardez simple pour les chemins sensibles à la latence sauf si vous avez une raison solide et des mesures justifiant la complexité.

Task 14: Confirm kernel-level pressure stalls (PSI) to see “waiting” clearly

cr0x@server:~$ cat /proc/pressure/io
some avg10=22.31 avg60=18.02 avg300=12.44 total=128381223
full avg10=8.44 avg60=6.10 avg300=4.01 total=42188122

Signification : Pression IO significative, y compris des stalls « full », signifie que des tâches sont fréquemment bloquées sur l’I/O. C’est votre preuve irréfutable quand les tableaux de bord sont ambigus.
Décision : Traitez cela comme un problème de capacité ou de mise en forme de la charge (réduire les écritures synchrones, ajouter des périphériques, isoler les voisins bruyants), pas comme un problème CPU.

Task 15: Validate application-level latency distribution (because averages lie)

cr0x@server:~$ curl -s localhost:9100/metrics | grep -E 'http_request_duration_seconds_bucket|http_request_duration_seconds_count' | head
http_request_duration_seconds_bucket{le="0.1"} 81234
http_request_duration_seconds_bucket{le="0.25"} 121882
http_request_duration_seconds_bucket{le="0.5"} 140012
http_request_duration_seconds_bucket{le="1"} 141100
http_request_duration_seconds_bucket{le="2.5"} 141360
http_request_duration_seconds_count 141420

Signification : Les buckets montrent le comportement de la queue. Si le compteur augmente mais que les buckets bas plafonnent, la queue s’aggrave.
Décision : Optimisez pour p95/p99, pas pour la moyenne. Si la queue coïncide avec la pression IO, corrigez d’abord le chemin IO.

Trois mini-histoires d’entreprise issues du terrain

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

Une entreprise SaaS de taille moyenne pour laquelle j’ai travaillé a fait un « refresh matériel » en catastrophe. CPUs plus récents, plus de cœurs, fréquences plus élevées.
Le dossier procurement était impeccable : coût par cœur en baisse, performance « attendue » en hausse. Ils ont déplacé un service stateful — appelons-le une API avec file — sur les nouveaux nœuds.

En quelques heures, la latence p99 a doublé et des timeouts sont apparus. Les graphes CPU semblaient corrects. L’astreignant a fait ce que font les gens quand le graphe est correct : il a blâmé l’appli.
L’équipe applicative a fait ce que font les gens quand on les blâme : ils ont envoyé une douzaine de captures d’écran et dit « ça marche en staging ».

La mauvaise hypothèse était simple : « CPU plus récent = service plus rapide ». En réalité, le refresh a changé le chemin de stockage. L’ancienne flotte avait des SSD locaux à latence stable.
La nouvelle flotte utilisait un backend de stockage partagé avec une latence d’écriture plus élevée et plus variable. Sous charge soutenue, c’était acceptable. Sous rafales, ça se mettait en file.

La correction n’a pas été héroïque. Ils ont séparé le journal d’écritures intensives du service sur un disque local et ont gardé les données en masse sur le stockage partagé.
Le p99 est revenu immédiatement. La leçon est restée : les refresh matériels sont des changements de plateforme. L’histoire d’Athlon n’était pas « un cœur plus rapide » non plus ; c’était un système global plus efficace.

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

Une autre organisation a décidé « d’optimiser » sa base de données en augmentant la concurrence. Plus de threads worker, plus grand pool de connexions, parallélisme plus élevé. Sur le papier, ils n’utilisaient que 40 % du CPU.
Ils ont supposé que le système avait de la marge. Ils ont aussi supposé que la latence resterait linéaire. Ce ne fut pas le cas.

Le premier symptôme était étrange : le débit a légèrement augmenté, mais la latence de queue est devenue sauvage. Le p50 s’est amélioré ; le p99 est devenu laid.
Les gens ont fêté le p50 et ignoré le p99 jusqu’à ce que les clients commencent à s’en apercevoir. C’est un mode d’échec classique : optimiser la médiane alors que l’activité vit dans la queue.

Ce qui s’est passé, c’était une amplification de verrous plus une amplification d’I/O. La plus grande concurrence a causé plus de contention dans la base, augmentant les commutations de contexte.
Le plus grand pool a aussi produit plus de pages sales et des tempêtes d’écriture plus fréquentes, saturant la file NVMe et transformant l’iowait en mode de vie.

Ils ont annulé l’augmentation de concurrence, puis fait le travail ennuyeux : limiter les connexions, tuner le checkpointing, ajouter une réplique en lecture pour les lectures en rafale, et déplacer un volume de log sur un périphérique avec un meilleur comportement d’écriture soutenue.
Le revers fut instructif : « CPU inutilisé » n’est pas une permission d’ajouter des threads. Cela peut signifier que vous attendez tout le reste.

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

Une équipe de services financiers exécutait un système batch qui devait se terminer avant l’ouverture des marchés. Rien de glamour — ETL, rapprochement, génération de rapports.
Un an, ils ont migré les nœuds de calcul. Pas parce qu’ils le voulaient, mais parce que le fournisseur leur a dit que l’ancienne plateforme arrivait en fin de vie.

Ils ont fait la seule chose qui marche sous pression : ils ont conservé une baseline. Pas une baseline sur slide — une exécutable.
Chaque semaine ils exécutaient le même jeu de jobs représentatifs, capturaient la latence IO, les profils CPU, et le temps de bout en bout. Ils le versionnaient comme du code.

Lors de la semaine de migration, la baseline a signalé une régression de 12 % dans le nouvel environnement. Pas catastrophique, mais suffisant pour manquer la coupure dans une mauvaise semaine.
Parce qu’ils l’ont trouvé tôt, ils ont eu le temps de corriger : le firmware du nouveau stockage avait par défaut un profil d’économie d’énergie qui augmentait la latence sous écritures par rafales.

Ils ont changé le profil, relancé la baseline, et signé. Pas d’incident. Pas d’héroïsme. Juste de la discipline de mesure.
C’est le même type de discipline qu’Athlon a imposé au marché : arrêtez de faire confiance aux valeurs par défaut, commencez à valider le comportement.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: high load average, low CPU utilization

Cause racine : threads bloqués en sommeil ininterruptible (généralement I/O de stockage, parfois NFS ou congestion du niveau bloc).

Correctif : Utilisez mpstat pour confirmer l’iowait, puis iostat -x et PSI (/proc/pressure/io) pour identifier les périphériques saturés. Réduisez les écritures synchrones, augmentez la capacité IOPS, ou séparez les chemins d’écriture chauds.

2) Symptom: CPU upgrade yields no throughput gain

Cause racine : goulot monothread, contention de verrou, ou dépendance externe (stockage/réseau) dominante.

Correctif : Utilisez perf top et pidstat -w. Si c’est verrous, réduisez la contention (shard, partition, redesign des sections critiques). Si c’est I/O, corrigez l’I/O.

3) Symptom: p50 improves but p99 worsens after “optimization”

Cause racine : file d’attente accrue due à une plus grande concurrence ; les buffers se remplissent ; tempêtes de writeback ; pauses GC ; sursouscription des pools de connexions.

Correctif : Limitez la concurrence. Mesurez la profondeur de file et await. Tuner le checkpointing/WAL DB, activer la rétro-pression, et cessez de traiter « plus de threads » comme une stratégie.

4) Symptom: random latency spikes with no obvious correlation

Cause racine : jobs périodiques (backup, vacuum, compaction), gestion d’alimentation firmware, ou I/O du voisin bruyant.

Correctif : Corrélez les pics avec cron/systemd timers, les profils firmware stockage, et la pression IO. Isolez les charges batch et validez les réglages d’alimentation du périphérique.

5) Symptom: network timeouts blamed on “slow server”

Cause racine : paquets perdus, retransmissions, déséquilibre des interruptions NIC, ou incompatibilité MTU provoquant fragmentation et perte.

Correctif : Vérifiez les pertes avec ip -s link, la santé des sockets avec ss -s, et la distribution des IRQ. Tuner RSS/affinity et valider le MTU bout en bout.

6) Symptom: disk shows low throughput but high latency

Cause racine : petites IO aléatoires, écritures sync, fréquence fsync, ou mismatch de profondeur de file.

Correctif : Optimisez le pattern I/O (regrouper écritures, séparation WAL), tunez le système de fichiers, et assurez-vous que le périphérique ne bride pas pour raison thermique ou d’alimentation (vérifier NVMe SMART).

Check-lists / plan étape par étape

Quand quelqu’un dit « le nouveau matériel est plus lent »

1. Exécutez uptime et mpstat pour classer CPU vs attente.
2. Si attente : lancez iostat -x et PSI IO pour identifier la saturation des périphériques.
3. Vérifiez la pression mémoire avec vmstat ; stoppez le swapping avant toute chose.
4. Vérifiez les pertes réseau avec ip -s link et la santé des sockets avec ss -s.
5. Capturez un profil CPU court (perf top) si CPU-bound.
6. Confirmez la topologie : numactl --hardware et distribution des IRQ.
7. Faites un changement à la fois. Re-mesurez. Conservez l’avant/après.

Avant d’approuver un projet « performance »

1. Exigez une charge représentative, pas seulement un benchmark synthétique.
2. Définissez le succès en p95/p99 et taux d’erreur, pas seulement en débit moyen.
3. Identifiez le goulot probable et comment il pourrait se déplacer après le changement.
4. Insistez sur des étapes de rollback et un plan canary.
5. Enregistrez une baseline réexécutable qui peut être relancée ultérieurement (versionnez-la).

Hygiène des changements de plateforme (sagesse de l’ère Athlon, modernisée)

1. Inventoriez les réglages firmware/BIOS qui modifient le comportement de latence (états d’alimentation, profils de performance).
2. Validez les versions de pilotes et les configs kernel pour les chemins de stockage et réseau.
3. Vérifiez que les options du système de fichiers et de montage correspondent au profil d’écriture de la charge.
4. Lancez des tests de soak assez longs pour attraper les pics d’entretien périodiques.

FAQ

1) Athlon était-il vraiment plus rapide qu’Intel sur tous les points ?

Non. Cela dépendait de la charge, de la plateforme et de la génération. L’essentiel est qu’Athlon a rendu « ça dépend » inévitable — et c’est ce qui a ébranlé le récit du gain par défaut d’Intel.

2) Pourquoi un SRE se soucie-t-il d’une rivalité CPU de 1999 ?

Parce que c’est une étude de cas sur les goulots, les effets de plateforme, et les métriques trompeuses. Vous luttez toujours contre le même ennemi : des hypothèses qui survivent plus longtemps qu’elles ne le méritent.

3) Quelle est l’équivalence moderne de « ne faites pas confiance aux MHz » ?

Ne faites pas confiance aux labels de type d’instance, aux comptes de vCPU, ou aux scores synthétiques uniques. Faites confiance à la latence p99 sous charge représentative, plus aux métriques de mise en file (IO, réseau, verrous).

4) Si mes CPU sont à 40 %, puis-je simplement augmenter la concurrence ?

Seulement si vous avez confirmé que vous n’êtes ni IO-bound, ni lock-bound, ni memory-bound. Un CPU inutilisé signifie souvent que le CPU attend poliment pendant que le vrai goulot brûle.

5) Quelle métrique révèle le plus vite la vérité ?

La latence et la pression IO (iowait + iostat await + PSI IO) pour les systèmes stateful ; pour les services stateless, les pertes de paquets et retransmissions sont des coupables « invisibles » fréquents.

6) Comment prouver que c’est le stockage et non le code applicatif ?

Montrez la corrélation : await en hausse, pression IO en hausse, p99 applicatif en hausse, et augmentation du temps passé en sommeil ininterruptible. Puis montrez l’amélioration après réduction de la charge IO ou ajout de capacité.

7) Quelle est la pratique de performance la plus simple et sûre que les équipes sautent ?

Une suite de tests baseline réexécutable avec métriques système enregistrées. Ennuyeuse, répétable — elle bat le débogage héroïque à chaque fois.

8) Comment arrêter le théâtre des benchmarks dans mon organisation ?

Exigez que toute proposition de benchmark inclue : description de la charge, forme du dataset, concurrence, warmup, p99, et un plan pour valider en production avec un canary.

9) Quel signal fiable indique qu’une « montée de gamme matérielle » est en réalité une régression de plateforme ?

Quand le CPU s’améliore mais que la latence I/O ou les pertes réseau empirent — et que l’expérience utilisateur se dégrade. Les changements de plateforme déplacent souvent le goulot vers une file que vous ne graphiez pas.

Conclusion : prochaines étapes que vous pouvez vraiment faire

Le véritable héritage d’Athlon n’est pas la fidélité à la marque. C’est le rappel que les systèmes gagnent quand ils gaspillent moins de temps à attendre.
Intel n’avait pas peur d’un logo ; il craignait un concurrent qui rendait les affirmations de performance mesurables et les choix d’achat discutables.
C’est ce que vous devriez aussi craindre : des décisions prises sans mesure.

Prochaines étapes pratiques :

• Choisissez un service critique et enregistrez une baseline : p50/p95/p99, CPU, latence IO, et pertes réseau sous une charge représentative.
• Ajoutez PSI (pression CPU/mémoire/IO) à votre tableau de dépannage par défaut ; cela raccourcit les débats.
• Rédigez un runbook « diagnostic rapide » d’une page pour votre équipe en utilisant le playbook ci-dessus, et entraînez-vous une fois.
• Quand quelqu’un propose « plus de threads » ou « des CPU plus gros », exigez la preuve que le goulot est réellement le CPU.