Pentium 4 / NetBurst : l’erreur la plus retentissante de l’ère des GHz

Thèse : les GHz étaient un indicateur, pas un produit

NetBurst a été conçu pour la fréquence. Pas « une bonne fréquence », pas « une fréquence efficace », mais « mettre le chiffre sur la boîte
et laisser le monde débattre après » fréquence. Intel venait de passer des années à entraîner les clients à interpréter la vitesse d’horloge
comme performance. Le marché récompensait cette simplification. Puis les factures sont arrivées : des pipelines d’instructions si profonds
que les mauvaises prédictions coûtent cher, un sous-système mémoire qui ne suivait pas, et une densité de puissance qui transformait
la conception des racks en hobby pour les passionnés de CVC.

Ce n’était pas un seul mauvais choix de conception. C’était un empilement de compromis qui supposaient tous une chose :
les fréquences continueraient d’augmenter, et les logiciels joueraient le jeu. Quand l’une ou l’autre hypothèse a échoué — code branché, charges lourdes
en mémoire, contraintes réalistes de datacenter — toute l’approche s’est effondrée.

Si vous voulez la traduction SRE : NetBurst optimisait le pic sous microbenchmarks idéaux et punissait la latence de queue
sous charge mixte en production. C’est une façon de livrer beaucoup de déception.

Exactement une fois, j’ai vu une diapositive d’achat traiter « 3.0 GHz » comme si c’était un SLA de débit.
C’est comme estimer la performance réseau en comptant les lettres de « Ethernet ».

Internes de NetBurst : le pipeline qui a mangé votre IPC

Pipelines profonds : excellent pour la fréquence, terrible pour les erreurs

L’histoire classique de NetBurst est « pipeline très profond ». L’histoire pratique est « pénalité de mauvaise prédiction élevée ».
Un pipeline plus profond vous aide à atteindre des fréquences plus élevées parce que chaque étape fait moins de travail. L’inconvénient est que vous avez maintenant
étiré la distance entre « on a deviné la branche » et « on découvre qu’on s’est trompé ». Quand on se trompe, on efface beaucoup de travail en vol et on recommence.

Les CPUs modernes pipelinent encore en profondeur, mais ils remboursent cela avec de meilleurs prédicteurs, des caches plus grands, une exécution plus large,
et une gestion de l’énergie soigneuse. NetBurst est allé profond tôt, avec des prédicteurs et des systèmes mémoire qui ne pouvaient pas complètement
couvrir le pari sur les parcours de code typiques des serveurs.

Trace cache : astucieux, complexe et sensible à la charge

Le trace cache de NetBurst stockait des micro-opérations décodées (uops), pas des instructions x86 brutes. C’était intelligent : décoder le x86 n’est
pas trivial, et un cache de uops peut réduire le coût d’avant-garde. Mais cela rendait aussi la performance plus dépendante de la façon dont le code
s’écoulait et s’alignait. Si votre flux d’instructions ne se comportait pas bien — beaucoup de branches, dispositions étranges, mauvaise localité — le
trace cache cessait d’être un cadeau et devenait un autre endroit où manquer.

L’idée n’était pas fausse ; elle était précoce et fragile. Les uop caches d’aujourd’hui réussissent parce que le reste du système s’est amélioré pour les alimenter,
et parce que les compromis puissance/perf sont gérés avec plus de finesse.

FSB et northbridge partagé : le péage de la bande passante

Les systèmes Pentium 4 reposaient sur un front-side bus (FSB) vers un contrôleur mémoire séparé (northbridge). Cela signifie que votre
cœur CPU est rapide, votre mémoire est « ailleurs », et chaque requête est un voyage sur un bus partagé. Sous charge, ce bus devient un problème d’ordonnancement.
Ajoutez plusieurs CPUs et c’est un travail d’équipe.

Comparez cela aux conceptions ultérieures avec contrôleurs mémoire intégrés (AMD l’a fait plus tôt sur x86 ; Intel a suivi). Quand
vous rapprochez la mémoire et lui donnez des chemins plus dédiés, vous réduisez la contention et baissez la latence. En production,
la latence est de la monnaie. NetBurst l’a dépensée comme un touriste.

Ère SSE2/SSE3 : fort en calcul streaming, inégal ailleurs

NetBurst s’en sortait bien dans certaines charges vectorisées et streaming — code qui pouvait traiter des tableaux de façon prévisible et éviter la logique branchée.
Voilà pourquoi les benchmarks pouvaient sembler corrects s’ils avaient été conçus pour alimenter la machine avec le type de travail qu’elle aimait. Mais les services réels ne sont pas polis.
Ils parsèment, branchent, allouent, verrouillent et attendent des E/S.

NetBurst était l’équivalent CPU d’un moteur réglé pour un circuit spécifique. Mettez-le en ville et vous apprendrez ce que signifie « courbe de couple ».

Pourquoi les charges réelles souffrent : caches, branches, mémoire et attente

IPC est ce que vous ressentez ; les GHz sont ce dont vous vous vantez

Instructions par cycle (IPC) est un proxy brutal mais utile pour « combien de travail est fait à chaque tick ». NetBurst avait souvent
un IPC inférieur à ses contemporains dans de nombreuses charges à usage général. Ainsi la puce tournait à une fréquence plus élevée pour compenser. Cela peut
marcher — jusqu’à ce que ça ne marche plus, parce que :

• Le code branché déclenche des mauvaises prédictions, qui coûtent plus cher dans les pipelines profonds.
• Les défauts de cache bloquent l’exécution, et un cœur rapide atteint simplement le blocage plus tôt.
• La latence FSB/mémoire devient un mur solide que vous ne pouvez pas contourner par horloge.
• La puissance/thermique force la réduction de fréquence, donc les GHz annoncés sont aspiratoires.

Mauvaise prédiction de branche : la taxe de latence que vous payez en continu

Les charges serveurs sont pleines de branches imprévisibles : routage de requêtes, parsing, vérifications d’autorisation, recherches dans des tables de hachage,
appels virtuels, décisions de compression, chemins d’exécution de bases de données. Quand les prédicteurs échouent, les pipelines profonds perdent
du travail et du temps. Le CPU ne « ralentit » pas. Il fait juste moins de travail utile tout en restant très occupé.

Mur mémoire : quand le cœur dépasse le système

NetBurst pouvait exécuter rapidement quand on le nourrissait, mais beaucoup de charges sont limitées par la mémoire. Un défaut de cache, ce sont des centaines de cycles
d’attente. Ce chiffre n’est pas une faute morale ; c’est de la physique plus de la topologie. L’effet pratique est qu’un CPU avec plus de GHz peut paraître pire s’il atteint
des stalls mémoire plus fréquemment ou ne peut pas les masquer efficacement.

Du point de vue de l’opérateur, cela se manifeste par : forte utilisation CPU, débit médiocre, et un système qui semble « bloqué » sans saturation évidente des E/S.
Ce n’est pas bloqué. Il attend la mémoire et se fight lui-même.

Exécution spéculative : utile, mais elle amplifie le coût des mauvaises hypothèses

La spéculation est la façon dont les CPUs modernes obtiennent des performances : deviner un chemin, l’exécuter, jeter si c’est faux. Dans un pipeline profond,
le mauvais chemin est cher. Le pari de NetBurst était que de meilleures horloges paieraient pour cela. Parfois ça marchait. Souvent, non.

L’une des leçons opérationnelles les plus simples de l’ère NetBurst : ne considérez pas « CPU à 95 % » comme « CPU fait 95 % de travail utile ».
Vous avez besoin de compteurs, pas d’impressions.

Thermique et puissance : quand votre CPU négocie avec la physique

La densité de puissance est devenue une caractéristique produit (par accident)

NetBurst chauffait. Surtout les Pentium 4 basés sur Prescott, qui sont devenus infâmes pour leur consommation et leur chaleur. La chaleur n’est pas seulement une facture d’électricité ; c’est un risque de fiabilité,
du bruit de ventilateurs et de la variabilité des performances.

En production, les cartes thermiques se transforment en cartes d’incident. Si une conception pousse fortement le refroidissement, votre marge disparaît :
filtres poussiéreux, ventilateur défaillant, une grille bouchée, une allée chaude qui dérive, ou un rack poussé trop près d’un mur devient un événement de performance. Et les événements de performance deviennent des événements de disponibilité.

Réduction thermique : le frein invisible

Lorsqu’un CPU réduit sa fréquence, l’horloge change, l’exécution change, et la latence de queue de votre service bascule de façons que vos tests de charge n’avaient jamais modélisées.
Avec les systèmes de l’ère NetBurst, il n’était pas rare de voir « le benchmark dit X » mais « la prod fait Y » parce que les conditions ambiantes n’étaient pas contrôlées comme en laboratoire.

Blague #1 : Prescott n’était pas un radiateur de remplacement, mais il rendait les astreintes hivernales un peu plus tolérables si vous étiez assis près du rack.

Fiabilité et exploitation : les systèmes chauds vieillissent plus vite

Condensateurs, VRM, ventilateurs et cartes mères n’aiment pas la chaleur. Même s’ils survivent, ils dérivent. Cette dérive devient des erreurs intermittentes, des redémarrages spontanés,
et des histoires de type « ça marche après qu’on l’ait reposé ». Ce n’est pas du mysticisme ; c’est dilatation thermique, alimentation marginale, et composants quittant leur zone de confort.

Une idée paraphrasée souvent attribuée à W. Edwards Deming s’applique clairement aux ops : « Vous ne pouvez pas gérer ce que vous ne mesurez pas. » Avec NetBurst, il fallait mesurer les thermiques,
parce que le CPU le faisait clairement.

Hyper-Threading : l’astuce utile qui a exposé de mauvaises hypothèses

L’Hyper-Threading (SMT) est arrivé sur certains modèles de Pentium 4 et était légitimement utile dans les bonnes conditions :
il pouvait remplir les bulles du pipeline en exécutant un autre thread quand un était en stall. Ça ressemble à de la performance gratuite,
et parfois ça l’était.

Quand ça aidait

• Charges mixtes où un thread attend des défauts de cache et l’autre peut utiliser les unités d’exécution.
• Services I/O lourds où un thread se bloque fréquemment et où le coût du scheduler est gérable.
• Certaines fonctions serveurs orientées débit avec requêtes indépendantes et faible contention sur les verrous.

Quand ça nuisait

• Charges limitées par la bande passante mémoire : deux threads se battent juste plus fort pour le même goulot.
• Charges avec verrous lourds : plus de contention, plus de bouncing de lignes de cache, pire latence de queue.
• Services sensibles à la latence : jitter lié aux ressources partagées et artefacts d’ordonnancement.

L’Hyper-Threading sur NetBurst est un bon microcosme d’une règle plus large : le SMT améliore de bons designs et rend les designs fragiles plus bizarres.
Il peut accroître le débit tout en rendant la latence plus laide. Si votre SLO est p99, vous ne l’« activez et priez » pas. Vous le testez avec une concurrence proche de la production et vous vérifiez la queue.

Faits historiques importants (et quelques piqûres qui restent)

1. NetBurst a débuté avec Willamette (Pentium 4, 2000), priorisant la vitesse d’horloge sur l’IPC.
2. Northwood a amélioré l’efficacité et les fréquences, et est devenu le Pentium 4 « moins douloureux » pour beaucoup d’acheteurs.
3. Prescott (2004) est passé à un processus plus petit, a ajouté des fonctionnalités, et est devenu notoire pour la chaleur et la consommation.
4. La « course aux GHz » a fortement modelé les décisions d’achat au point que « horloge plus élevée » battait souvent une meilleure architecture dans les ventes.
5. L’accès mémoire basé FSB signifiait que le CPU rivalisait pour la bande passante sur un bus partagé vers le northbridge.
6. Le trace cache stockait des micro-ops décodés, visant à réduire le coût du décodage et à alimenter efficacement le long pipeline.
7. Hyper-Threading est arrivé sur certains modèles et pouvait améliorer le débit en utilisant des ressources d’exécution inoccupées.
8. Pentium M (dérivé de la lignée P6) surpassait souvent le Pentium 4 à des fréquences bien plus basses, surtout dans les tâches réelles.
9. Intel a finalement pivoté loin de NetBurst ; Core (basé sur une lignée différente) a remplacé la stratégie plutôt que de l’itérer indéfiniment.

Trois mini-histoires d’entreprise sorties des tranchées

Mini-histoire 1 : l’incident causé par une mauvaise hypothèse (« GHz = capacité »)

Une entreprise de taille moyenne a hérité d’une flotte de serveurs web vieillissants et prévu un rafraîchissement rapide. Les critères de sélection étaient
douloureusement simples : choisir les boîtiers Pentium 4 à la fréquence la plus élevée dans le budget. La note d’achat a littéralement assimilé
« +20 % d’horloge » à « +20 % de requêtes par seconde ». Personne n’était malveillant ; ils étaient occupés.

Le déploiement s’est bien passé jusqu’à ce que le trafic atteigne son pic habituel. L’utilisation CPU semblait correcte — élevée mais stable.
Le réseau était sous contrôle. Les disques ne hurlaient pas. Pourtant la latence p95 a augmenté, puis le p99 est parti verticalement. L’équipe d’astreinte
a fait ce que font les équipes : redémarré des services, déplacé le trafic, blâmé le load balancer, et regardé les graphiques jusqu’à ce que les graphiques les regardent en retour.

Le vrai problème était le comportement mémoire. La charge avait évolué au fil des ans : plus de personnalisation, plus de logique de template, plus de routage dynamique.
Cela signifiait plus de chasing de pointeurs et de branchements. Les nouveaux serveurs avaient des horloges plus élevées mais une latence mémoire similaire et une topologie FSB partagée
qui empirait sous concurrence. Ils atteignaient plus vite les mêmes stalls mémoire, et l’Hyper-Threading ajoutait de la contention au pire moment.

La solution n’était pas « tuner Linux davantage ». La solution a été de rebaseliner la capacité en utilisant un test proche de la production :
concurrence réaliste, phases cache-chaud et cache-froid, et la latence de queue comme métrique de première classe. L’entreprise a fini par modifier la composition de la flotte :
moins de machines « haute fréquence », plus de nœuds équilibrés avec de meilleurs sous-systèmes mémoire. Ils ont aussi arrêté d’utiliser les GHz comme principal nombre de capacité.
Des miracles arrivent quand vous arrêtez de vous mentir.

Mini-histoire 2 : l’optimisation qui a échoué (« activer HT pour obtenir des performances gratuites »)

Une autre équipe faisait tourner un service Java avec beaucoup de requêtes courtes. Ils ont activé l’Hyper-Threading sur toute la flotte
et doublé les threads travailleurs, s’attendant à des gains de débit linéaires. Les premiers tests synthétiques semblaient excellents. Puis les rapports d’incident sont arrivés :
pics de latence sporadiques, pauses GC qui coïncidaient avec des rafales de trafic, et un nouveau type de « c’est lent mais rien n’est saturé ».

Le système n’était pas en panne CPU ; il était en panne de cache et de verrous. Deux CPU logiques partageaient des ressources d’exécution
et, plus important, le cache partagé et les chemins de bande passante mémoire. Les patterns d’allocation et de synchronisation de la JVM créaient du bouncing de lignes de cache,
et la concurrence supplémentaire a amplifié la contention dans des hotspots auparavant insignifiants.

Ils ont essayé de corriger en augmentant la taille du heap, en affinant l’affinité des threads, puis en tournant des boutons qui faisaient « système ». Certains ont aidé, la plupart non.
Le vrai gain est venu en prenant du recul : traiter l’Hyper-Threading comme un outil de débit avec un coût en latence. Mesurez le coût.

Ils sont revenus à moins de threads workers, ont activé HT uniquement sur les nœuds servant du batch non interactif, et ont utilisé le profilage applicatif pour supprimer quelques goulots de verrous.
Le débit a fini légèrement supérieur à l’avant « optimisation », et la latence de queue est redevenue ennuyeuse. La leçon n’était pas « HT est mauvais ». La leçon était « HT est un multiplicateur, et il multiplie aussi vos erreurs ».

Mini-histoire 3 : la pratique ennuyeuse mais correcte qui a sauvé la mise (« marge thermique = capacité »)

Une équipe de services financiers exécutait des jobs nocturnes intensifs sur un cluster incluant des nœuds Pentium 4 de l’ère Prescott. Personne n’aimait ces boîtiers,
mais les jobs étaient stables et le cluster « suffisait ». Le super-pouvoir discret de l’équipe était qu’ils traitaient l’environnement comme faisant partie de la capacité :
surveillance de la température d’entrée d’air, contrôles de santé des ventilateurs, et alertes sur les indicateurs de throttling thermique.

Un été, une unité de refroidissement s’est dégradée pendant un week-end. Pas une panne complète — juste une sous-performance. Lundi matin, les durées de job ont augmenté lentement.
La plupart des équipes auraient blâmé le scheduler ou la base de données. Cette équipe a remarqué une corrélation subtile : des nœuds dans une rangée montraient des relevés thermiques légèrement plus élevés
et une fréquence CPU effective légèrement plus basse.

Ils ont vidangé ces nœuds, déplacé les jobs vers des racks plus frais, et ouvert un ticket facilities avec des preuves concrètes. Ils ont aussi réduit temporairement la concurrence par nœud
pour diminuer la production de chaleur et stabiliser les temps d’exécution. Pas de drame, pas d’héroïsme, pas de salle de crise à minuit.

Le résultat : les jobs ont fini à l’heure, pas d’incident côté client, et le problème de refroidissement a été réparé avant qu’il ne devienne une fête des défaillances matérielles.
La pratique était ennuyeuse — mesurer les thermiques, surveiller le throttling, maintenir une marge — mais elle a transformé un « ralentissement mystérieux » en un changement contrôlé. L’ennuyeux est sous-estimé.

Tâches pratiques : 12+ commandes pour diagnostiquer « CPU rapide, système lent »

Celles-ci sont exécutables sur un serveur Linux typique. Vous n’essayez pas de « prouver que NetBurst est mauvais » en 2026.
Vous apprenez à reconnaître les mêmes modes de défaillance : stalls de pipeline, mur mémoire, artefacts d’ordonnancement,
throttling thermique, et utilisation trompeuse.

Task 1: Identify the CPU and whether HT is present

cr0x@server:~$ lscpu
Architecture:            x86_64
CPU op-mode(s):          32-bit, 64-bit
CPU(s):                  2
Thread(s) per core:      2
Core(s) per socket:      1
Socket(s):               1
Model name:              Intel(R) Pentium(R) 4 CPU 3.00GHz
Flags:                   fpu vme de pse tsc ... ht ... sse2

Ce que cela signifie : « Thread(s) per core: 2 » indique l’Hyper-Threading. Le nom du modèle vous donne la famille.

Décision : Si HT est présent, faites des benchmarks avec HT activé/désactivé pour les services sensibles à la latence ; n’assumez pas que c’est un gain.

Task 2: Check current frequency and scaling driver

cr0x@server:~$ grep -E 'model name|cpu MHz' /proc/cpuinfo | head
model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
cpu MHz		: 2793.000

Ce que cela signifie : Le CPU n’est pas à sa fréquence nominale. Cela peut être de l’économie d’énergie ou du throttling.

Décision : Si la fréquence est anormalement basse sous charge, investiguez les gouverneurs et le throttling thermique ensuite.

Task 3: Confirm the CPU frequency governor

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

Ce que cela signifie : « ondemand » peut réduire la fréquence jusqu’à ce que la charge augmente ; sur les plateformes plus anciennes il peut répondre lentement.

Décision : Pour les services à faible latence, envisagez « performance » et retestez ; pour du batch, « ondemand » peut convenir.

Task 4: Look for thermal zones and temperatures

cr0x@server:~$ for z in /sys/class/thermal/thermal_zone*/temp; do echo "$z: $(cat $z)"; done
/sys/class/thermal/thermal_zone0/temp: 78000
/sys/class/thermal/thermal_zone1/temp: 65000

Ce que cela signifie : Les températures sont en millidegrés Celsius. 78000 = 78°C.

Décision : Si les températures approchent les seuils de throttling pendant le pic, traitez le refroidissement comme un limiteur de capacité, pas comme une « anecdote facilities ».

Task 5: Detect throttling indicators in kernel logs

cr0x@server:~$ dmesg | grep -i -E 'throttl|thermal|critical|overheat' | tail
CPU0: Thermal monitoring enabled (TM1)
CPU0: Temperature above threshold, cpu clock throttled
CPU0: Temperature/speed normal

Ce que cela signifie : Le CPU a réduit sa vitesse à cause de la chaleur. Votre « mystère » de débit peut être de la simple physique.

Décision : Corrigez le flux d’air/le refroidissement, réduisez la charge ou réduisez la concurrence. Ne touchez pas au logiciel pour compenser un défaut thermique.

Task 6: Check run queue and CPU saturation quickly

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 120000  15000 210000    0    0     2     5  900 1400 85 10  5  0  0
 4  0      0 118000  15000 209000    0    0     0     8 1100 1800 92  7  1  0  0

Ce que cela signifie : « r » (file d’exécution) constamment au-dessus du nombre de CPU implique une contention CPU. Un « id » bas signifie occupé.

Décision : Si la file d’exécution est élevée, vous êtes saturé CPU ou en stall. Ensuite : déterminer si c’est calcul, mémoire ou verrous.

Task 7: Identify top CPU consumers and whether they’re spinning

cr0x@server:~$ top -b -n 1 | head -n 15
top - 12:14:01 up 21 days,  3:11,  1 user,  load average: 3.90, 3.60, 3.20
Tasks: 184 total,   2 running, 182 sleeping,   0 stopped,   0 zombie
%Cpu(s): 92.0 us,  7.0 sy,  0.0 ni,  1.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
2174 app      20   0  1856m  612m  122m R  98.7  7.6  12:11.02 java

Ce que cela signifie : Un CPU utilisateur élevé peut quand même être « en attente » (stalls mémoire, mauvaises prédictions). Un « wa » bas n’invalide pas l’occupation CPU.

Décision : Si un processus domine, profilez-le ; si beaucoup partagent, suspectez une contention systémique ou des effets du scheduler.

Task 8: Check context switching and interrupt pressure

cr0x@server:~$ pidstat -w 1 5
Linux 6.1.0 (server) 	01/09/2026 	_x86_64_	(2 CPU)

12:14:20      UID       PID   cswch/s nvcswch/s  Command
12:14:21     1001      2174   1200.00    350.00  java

Ce que cela signifie : Des switches de contexte très élevés peuvent impliquer trop de threads, de la contention sur les verrous, ou du churn timer/IO.

Décision : Si cswch/s est élevé et la latence mauvaise, réduisez le nombre de threads ou corrigez les hotspots de verrou avant d’acheter du matériel.

Task 9: Look at memory bandwidth stress signals via perf (cycles vs stalled frontend/backend)

cr0x@server:~$ sudo perf stat -p 2174 -e cycles,instructions,branches,branch-misses,cache-misses -a -- sleep 10
 Performance counter stats for 'system wide':

     32,100,000,000      cycles
     12,400,000,000      instructions              #    0.39  insn per cycle
      2,900,000,000      branches
        145,000,000      branch-misses             #    5.00% of all branches
        610,000,000      cache-misses

Ce que cela signifie : Un IPC bas (0.39) plus des défauts cache/branche élevés suggèrent que le CPU est occupé mais peu productif.

Décision : Optimisez les chemins de code pour la localité/la prédictibilité des branches, ou choisissez un CPU avec meilleur IPC et gestion mémoire.

Task 10: Confirm whether you’re actually I/O bound

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          90.50    0.00    7.20    0.10    0.00    2.20

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await
sda              2.10    1.00   45.0    28.0     0.0     0.2    3.0    1.2

Ce que cela signifie : Le disque est peu utilisé ; await est bas. Ce n’est pas un goulot de stockage.

Décision : Arrêtez de blâmer les disques. Concentrez-vous sur CPU/mémoire/verrouillage et le profilage au niveau requête.

Task 11: Check memory pressure and paging (the silent performance killer)

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:            2048        1720         120          12         207         210
Swap:           2048         900        1148

Ce que cela signifie : L’utilisation du swap peut être acceptable, mais si du paging actif survient sous charge vous verrez des stalls et des pics.

Décision : Si l’activité swap corrèle avec la latence, réduisez l’empreinte mémoire, ajoutez de la RAM, ou ajustez le placement des charges.

Task 12: Verify active paging, not just swap usage

cr0x@server:~$ sar -B 1 5
Linux 6.1.0 (server) 	01/09/2026 	_x86_64_	(2 CPU)

12:15:10  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgsteal/s
12:15:11      0.00      0.00    820.00      0.00   1200.00      0.00      0.00
12:15:12     10.00     45.00   2100.00     15.00    400.00    800.00    300.00

Ce que cela signifie : Les fautes majeures (majflt/s) et le scanning indiquent une vraie pression mémoire.

Décision : Le paging sous charge est un problème de capacité. Réparez la mémoire, pas les flags CPU.

Task 13: Inspect scheduler pressure at a glance

cr0x@server:~$ cat /proc/pressure/cpu
some avg10=12.34 avg60=10.01 avg300=8.55 total=987654321

Ce que cela signifie : Le PSI CPU « some » indique le temps que les tâches passent à attendre des ressources CPU.

Décision : Si le PSI monte avec la latence, vous avez besoin d’un CPU plus efficace (IPC), de moins de threads exécutables, ou d’un écrêtage de charge.

Task 14: Detect lock contention (often misdiagnosed as “slow CPU”)

cr0x@server:~$ sudo perf top -p 2174
Samples: 31K of event 'cpu-clock', 4000 Hz, Event count (approx.): 7750000000
Overhead  Shared Object        Symbol
  12.40%  libc.so.6            [.] pthread_mutex_lock
   9.10%  libjvm.so            [.] SpinPause

Ce que cela signifie : Le temps est passé dans les verrous et le spinning, pas dans du travail productif.

Décision : Réduisez la contention (sharder les verrous, réduire les threads, corriger les sections critiques chaudes). Plus de GHz ne vous sauvera pas.

Task 15: Validate cache friendliness via a quick microbenchmark stance (not a substitute for real tests)

cr0x@server:~$ taskset -c 0 sysbench cpu --cpu-max-prime=20000 run
CPU speed:
    events per second:  580.21

General statistics:
    total time:                          10.0004s
    total number of events:              5804

Ce que cela signifie : Un test fortement compute peut paraître « correct » même si votre service est limité par la mémoire/les branches.

Décision : Utilisez les microbenchmarks uniquement pour une validation de base ; basez vos décisions sur des tests représentatifs de la charge et sur la latence.

Blague #2 : Si votre plan est « ajouter des threads jusqu’à ce que ça aille vite », vous n’optimisez pas — vous invoquez des démons de contention.

Roue de diagnostic rapide : ce qu’il faut vérifier d’abord/deuxièmement/troisièmement

Voici le raccourci orienté production pour les surprises de type NetBurst : systèmes qui paraissent « riches en CPU » sur le papier mais deviennent lents sous charges réelles.
Vous voulez le goulot vite, pas un débat philosophique sur la microarchitecture.

Premier : vérifiez que le CPU que vous pensez avoir est bien celui que vous obtenez

1. Fréquence sous charge : vérifiez /proc/cpuinfo MHz, le gouverneur de scaling, et dmesg pour le throttling.
2. Thermiques : vérifiez les zones thermiques et l’état des ventilateurs/flux d’air via la télémétrie disponible.
3. Virtualisation : confirmez que vous n’êtes pas limité par des quotas CPU ou des voisins bruyants (PSI, cgroups).

Objectif : éliminer « le CPU ne tourne littéralement pas à la vitesse attendue » en moins de 5 minutes.

Second : déterminez si vous êtes lié au calcul, à la mémoire, ou à la contention

1. File d’exécution et PSI : vmstat et /proc/pressure/cpu pour l’attente CPU.
2. IPC via perf : cycles vs instructions ; un IPC bas suggère stalls/défauts.
3. Signaux de contention sur les verrous : perf top, pidstat context switches, dumps de threads applicatifs.

Objectif : classer la douleur. Vous ne pouvez pas réparer ce que vous ne nommez pas.

Troisième : confirmez que ce n’est pas I/O et pas du paging

1. Disque : iostat -xz pour l’utilisation et l’await.
2. Paging : sar -B pour les fautes majeures et le scanning.
3. Réseau : vérifiez les drops/erreurs et l’encombrement des files (non montrés ci-dessus, mais à faire).

Objectif : arrêter de perdre du temps sur le mauvais sous-système.

Quatrième : décidez si c’est un problème d’adéquation matériel ou logiciel

• Si l’IPC est bas à cause des défauts de cache et des mauvaises prédictions, vous avez besoin d’une meilleure localité ou d’un CPU avec meilleur IPC — pas plus de GHz.
• Si la contention domine, réduisez la concurrence ou redessinez les chemins chauds — les upgrades matériels ne résoudront pas du code sérialisé.
• Si du throttling est présent, corrigez le refroidissement et l’alimentation d’abord ; sinon chaque autre changement est du bruit.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptom: “CPU is pegged, but throughput is mediocre”

Cause racine : IPC bas dû à des défauts de cache, des mauvaises prédictions ou la latence mémoire ; le CPU paraît occupé mais est en stall.

Correctif : Utilisez perf stat pour confirmer un IPC bas et des défauts élevés ; optimisez la localité, réduisez le pointer chasing, et profilez les chemins chauds. Si vous achetez du matériel, priorisez l’IPC et le sous-système mémoire, pas l’horloge.

2) Symptom: “Latency spikes appear only during warm afternoons / after a fan replacement”

Cause racine : Throttling thermique ou mauvais flux d’air provoquant des baisses de fréquence et du jitter.

Correctif : Confirmez via dmesg et les lectures des zones thermiques ; remédiez au refroidissement, nettoyez les filtres, vérifiez les courbes des ventilateurs, et conservez une marge de température d’entrée. Traitez les thermiques comme une dépendance SLO de première classe.

3) Symptom: “We enabled Hyper-Threading and p99 got worse”

Cause racine : Contention des ressources partagées (unités d’exécution/caches), augmentation de la contention sur les verrous, ou saturation de la bande passante mémoire.

Correctif : Testez A/B HT on/off avec une concurrence proche de la production ; réduisez le nombre de threads ; corrigez les hotspots de verrous ; envisagez HT uniquement pour les charges orientées débit ou bloquées I/O.

4) Symptom: “Microbenchmarks improved, production got slower”

Cause racine : Les microbenchmarks sont compute-heavy et prévisibles ; la production est branchée et mémoire-intensive. Les designs type NetBurst récompensent le premier et punissent le second.

Correctif : Benchmarchez avec des mix de requêtes réalistes, phases cache-chaud/froid, et la latence de queue. Incluez concurrence, comportement de l’allocateur, et tailles de données réalistes.

5) Symptom: “Load average increased after we ‘optimized’ by adding threads”

Cause racine : Sur-souscription et contention ; plus de threads exécutables augmentent l’ordonnancement et le coût des verrous.

Correctif : Utilisez pidstat pour mesurer les context switches, perf top pour les symboles de verrou, et réduisez la concurrence. Ajoutez du parallélisme seulement là où le travail est réellement parallèle et où le goulot se déplace.

6) Symptom: “CPU upgrades didn’t help the database”

Cause racine : La charge est liée à la latence mémoire ou à la bande passante mémoire (défauts du buffer pool, pointer chasing dans les B-trees, défauts de cache).

Correctif : Augmentez le hit rate effectif du cache (indexes, forme des requêtes), ajoutez de la RAM, réduisez le working set, et mesurez les défauts de cache/IPC. Ne jetez pas des GHz contre un mur mémoire.

7) Symptom: “Everything looks fine except occasional pauses and timeouts”

Cause racine : Paging, pauses GC, ou pics de contention qui n’apparaissent pas comme une utilisation soutenue.

Correctif : Vérifiez les fautes majeures, le PSI, et les métriques de pause applicatives. Corrigez la pression mémoire et réduisez l’amplification de queue (timeouts, retries, thundering herds).

Listes de contrôle / plan pas à pas

Checklist A: Buying hardware without repeating the NetBurst mistake

1. Définir le succès par la latence et le débit (p50/p95/p99 + RPS soutenu), pas par la vitesse d’horloge.
2. Mesurer des proxies d’IPC : utilisez perf sur des charges représentatives ; comparez cycles/instructions et taux de défaut.
3. Modéliser le comportement mémoire : taille du working set, taux de hits cache, concurrence prévue, et besoins de bande passante.
4. Valider les thermiques : testez en rack, avec température ambiante réaliste et profils de ventilateurs.
5. Tester l’impact SMT/HT : on/off, avec nombres de threads réels et suivi de la latence de queue.
6. Privilégier les systèmes équilibrés : canaux mémoire, tailles de cache et interconnexions comptent autant que les fréquences des cœurs.

Checklist B: When a “faster CPU” deployment makes production slower

1. Confirmer la fréquence et le throttling (gouverneur, températures, dmesg).
2. Comparer l’IPC et les taux de défaut via perf avant/après.
3. Vérifier les nombres de threads et le context switching ; rollback des changements « double threads » en priorité.
4. Valider la pression mémoire et le paging ; corriger les fautes majeures immédiatement.
5. Rechercher des régressions de contention de verrous introduites par la nouvelle concurrence.
6. Si encore obscur, capturez un flame graph ou équivalent et examinez-le comme une timeline d’incident.

Checklist C: Stabilize tail latency on old, hot, frequency-chasing systems

1. Réduire la concurrence pour correspondre aux cœurs (surtout avec HT) et observer l’impact sur le p99.
2. Pinnez les threads critiques uniquement si vous comprenez votre topologie ; sinon vous risquez de vous enfermer.
3. Maintenez un gouverneur CPU cohérent (souvent « performance » pour les nœuds critiques en latence).
4. Faites respecter la marge thermique : alertez sur la température et les événements de throttling, pas seulement sur l’utilisation CPU.
5. Optimisez les chemins chauds pour la localité ; éliminez les branches imprévisibles quand c’est possible.
6. Introduisez du backpressure et des timeouts sensés pour éviter les amplifications par retries.

FAQ

1) Was Pentium 4 actually “bad,” or just misunderstood?

C’était un pari étroit. Dans les charges qui correspondaient à ses forces (streaming, code prévisible, fort levier de fréquence),
il pouvait bien performer. Dans des charges serveurs mixtes, il livrait souvent une performance réelle par watt et par dollar pire que les alternatives.
« Mal compris » est généreux ; « mal vendu » est plus proche.

2) Why did higher GHz not translate into higher performance?

Parce que la performance dépend du travail utile par cycle (IPC) et de la fréquence des stalls mémoire, branches et contentions.
NetBurst augmentait le nombre de cycles mais réduisait souvent le travail utile par cycle sous charges réelles.

3) What’s the operational lesson for modern systems?

N’acceptez pas une métrique d’accroche unique. Pour les CPU c’est les GHz ; pour le stockage c’est les « IOPS » ; pour les réseaux c’est les « Gbps ».
Demandez toujours : sous quelle latence, avec quelle concurrence, et quel comportement de queue ?

4) Did Hyper-Threading “fix” NetBurst?

Cela a aidé le débit dans certains cas en remplissant des créneaux d’exécution inoccupés, mais cela n’a pas changé les fondamentaux :
pénalités de pipeline profond, goulots mémoire, et contraintes thermiques. Cela pouvait aussi aggraver la latence de queue en ajoutant de la contention.
Traitez-le comme un réglage, pas comme un bien par défaut.

5) Why did Pentium M sometimes beat Pentium 4 at much lower clocks?

Pentium M (de la lignée P6) mettait l’accent sur l’IPC et l’efficacité. Dans des charges branchées et sensibles au cache, un IPC plus élevé
plus une meilleure efficacité surpassent souvent une fréquence brute, surtout quand la fréquence provoque du throttling thermique.

6) How can I tell if my workload is memory-bound instead of CPU-bound?

Recherchez un IPC bas avec beaucoup de défauts de cache dans perf, plus une amélioration limitée quand vous ajoutez des cœurs ou augmentez la fréquence.
Vous verrez aussi le débit plafonner pendant que le CPU reste « occupé ». C’est généralement un mur mémoire ou de contention.

7) Is thermal throttling really common enough to matter?

Sur des designs qui chauffent et dans des datacenters réels, oui. Même un throttling modeste crée du jitter. Le jitter devient latence de queue,
et la latence de queue devient incidents quand retries et timeouts amplifient la charge.

8) What should I benchmark to avoid GHz-era mistakes?

Benchmarchez le service réel : mix de requêtes réaliste, taille de dataset réaliste, concurrence réaliste, et reportez p95/p99 + débit.
Ajoutez une phase cache-froid et un run soutenu assez long pour chauffer le système.

9) Are there modern equivalents of the NetBurst trap?

Oui. Chaque fois que vous optimisez une métrique de pic au détriment du comportement systémique : fréquences turbo sans budget thermique,
benchmarks de stockage qui ignorent la latence fsync, ou tests de débit réseau qui ignorent la perte de paquets sous charge. Le schéma est le même :
le pic gagne la diapositive, la queue perd le client.

Conclusion : que faire la prochaine fois qu’on vous vend des GHz

NetBurst n’est pas juste une anecdote CPU rétro. C’est une histoire claire sur les incitations, la mesure, et le coût de parier sur un seul nombre.
Intel a optimisé pour la fréquence parce que le marché payait pour la fréquence. Les charges qui importaient —
code branché, systèmes mémoire-intensifs, racks contraints thermiquement — ont envoyé la facture.

Les étapes pratiques suivantes sont ennuyeuses, et c’est pourquoi elles fonctionnent :

1. Définir la performance par la latence de queue, pas par le débit de pic et surtout pas par la vitesse d’horloge.
2. Instrumenter pour les goulots : compteurs perf, PSI, métriques de paging, et signaux thermiques/throttling.
3. Benchmarchez comme en production : concurrence, taille des données, comportement cache, soak thermique, et mix de requêtes réaliste.
4. Traitez les thermiques comme de la capacité : si le CPU throttle, votre architecture est « limitée par le refroidissement ». Admettez-le.
5. Soyez méfiant des « performances gratuites » : HT/SMT, concurrence agressive, et micro-optimisations qui ignorent la contention.

Si vous ne retenez qu’une chose : les horloges sont un composant, pas une garantie. Le système est le produit. Exploitez-le comme tel.