Core et Core 2 : le retour d’Intel après NetBurst (et ce qu’en ont appris les ops)

janvier 13, 2026 • février 3, 2026 • Lecture : 27 min • Views: 0

Cet article vous a aidé ?

Vous ne ressentez pas une architecture CPU dans un tableau de benchmark. Vous la ressentez à 03:12 quand la latence tail explose, que la base de données commence à « bloquer mystérieusement » et que l’astreinte essaie de se repérer sur un graphe qui ressemble à un moniteur cardiaque.

Le pivot d’Intel de NetBurst (Pentium 4, Pentium D) vers Core/Core 2 n’était pas une simple mise à jour marketing. C’était une remise à zéro sur ce qui compte : travail par cycle, latence prévisible et consommation que vous pouvez réellement refroidir. Si vous administrez des systèmes de production — ou que vous les héritez — comprendre ce changement vous aide à diagnostiquer des pannes qui réapparaissent encore aujourd’hui sous d’autres noms.

NetBurst : quand les GHz sont devenus le produit

NetBurst était le pari d’Intel au début des années 2000 que l’avenir serait la fréquence. L’ère Pentium 4 a appris aux acheteurs à poser une seule question : « Combien de GHz ? » NetBurst a essayé de rendre cette question facile en poussant la fréquence via une pipeline très profonde et des choix de conception agressifs pensés pour des horloges élevées.

Et pendant un temps, cela a « fonctionné » au sens le plus étroit : les fréquences ont augmenté. Mais les systèmes ne fonctionnent pas sur des horloges ; ils fonctionnent sur du travail accompli. En termes d’exploitation, NetBurst a livré une combinaison pénible : forte consommation, contraintes thermiques et performances très variables selon le comportement des branches, les ratés de cache et la latence mémoire.

Voici ce qui a frappé les charges de production :

Les pipelines profonds signifiiaent que les mauvaises prédictions de branche coûtent cher. Si votre charge a des branches imprévisibles (compression, chiffrement, parsing, sorties de VM), vous en payez le prix.
La forte densité de puissance fait atteindre les limites thermiques plus vite. Cela se traduit par du throttling, des ventilateurs à fond et des incidents « pourquoi ce nœud est-il plus lent que son jumeau ? ».
La dépendance au front-side bus maintenait l’accès mémoire comme un goulot partagé. Si plusieurs cœurs (bonjour, Pentium D) se battent pour le même bus, la latence n’est pas une théorie — c’est votre profondeur de file d’attente.

NetBurst n’était pas du « mauvais ingénierie ». C’était de l’ingénierie optimisée pour une incitation marché : vendre des GHz. La facture a été payée par tous ceux qui essayaient d’exécuter des charges mixtes sur des serveurs x86 standards.

Petite blague #1 : NetBurst, c’était comme promettre de livrer des colis plus vite en achetant un camion plus rapide, puis découvrir que votre quai de chargement ne reçoit qu’un seul camion à la fois.

Pourquoi la « course aux GHz » s’est effondrée dans les systèmes réels

La fréquence est un multiplicateur. Si le travail par cycle est bas, vous pouvez multiplier toute la journée et ne pas obtenir ce que vous voulez. La profondeur de pipeline de NetBurst a augmenté le coût des moments « oups » : mauvaises prédictions de branche, ratés de cache, flushs de pipeline. Les serveurs sont pleins de moments « oups » parce que le code de production réel est désordonné : beaucoup de branches, beaucoup de chasing de pointeurs, beaucoup d’attente mémoire ou I/O.

La consommation a rendu le problème indéniable. Plus de fréquence nécessitait plus de tension ; plus de tension signifiait plus de chaleur ; la chaleur signifiait des limites ; les limites signifiaient du throttling ou des horloges moins élevées atteignables. Les centres de données se moquent de votre diapositive marketing — vos baies se préoccupent de watts et du flux d’air.

Core : le moment « arrêtez de creuser »

L’architecture Core d’Intel (commencée sur mobile, puis étendue) était en fait une reconnaissance que NetBurst n’était pas la voie pour une performance soutenable. La philosophie interne s’est tournée vers l’IPC (instructions par cycle), l’efficacité et une conception système équilibrée.

Si NetBurst disait « nous forcerons la fréquence », Core disait « nous ferons plus de travail utile par tic et gâcherons moins d’énergie pour y parvenir ». Cela impliquait des améliorations sur :

Des pipelines plus courts et plus efficaces, réduisant les pénalités de mauvaise prédiction.
Une meilleure prédiction de branche, ce qui compte pour le code serveur plus qu’on ne veut l’admettre.
Un comportement de cache plus efficace, incluant des caches partagés plus grands et plus utiles dans Core 2.
La gestion de la puissance qui ne traite pas le CPU comme un radiateur programmable.

Pour les ops, Core signifiait que vous pouviez commencer à faire confiance à ce qu’un « CPU plus efficace » se traduise par une latence tail plus faible, pas seulement un débit de pointe plus élevé dans un benchmark étroit.

Core 2 : le retour qui a tenu

Core 2 (Conroe/Merom/Woodcrest) n’était pas juste « Core, mais plus rapide ». Il s’est imposé comme un remplaçant crédible des systèmes Pentium 4/Pentium D sur postes et serveurs, et il a changé l’achat et la planification de capacité du jour au lendemain.

Les gains visibles pour les ops avec Core 2 :

Meilleure performance par watt : vous pouviez mettre plus de calcul dans le même budget énergétique sans cuire l’allée.
IPC plus élevé : les charges branchées ou sensibles à la mémoire s’amélioraient sans compter sur des horloges extrêmes.
Cache L2 partagé (commun à de nombreuses conceptions Core 2) : deux cœurs pouvaient coopérer au lieu d’agir comme des colocataires se battant pour la cuisine.

Et la vérité moins glamour : Core 2 a aussi rendu la performance plus prévisible. La prévisibilité est une fonctionnalité SRE. Vous ne pouvez pas autoscaler votre chemin hors d’une latence chaotique.

Ce que « l’IPC bat les GHz » signifie en production

Les améliorations d’IPC apparaissent dans des endroits que vous ne classeriez pas forcément comme « CPU-bound ». Par exemple, une couche web sous terminaison TLS peut sembler « liée au réseau » jusqu’à ce que vous réalisiez que le CPU dépense des cycles en crypto et en logique de handshake. Un cœur avec meilleur IPC réduit le temps dans ces hotspots et réduit les délais d’attente en file. Même chose pour les piles de stockage : checksums, compression, parité RAID, traitement de paquets, gestion du noyau — le CPU compte.

Core 2 n’a pas fait disparaître la latence mémoire. Il n’a pas non plus supprimé le front-side bus dans cette génération. Mais il a amélioré la capacité du cœur à cacher des latences et à faire du travail utile, si bien que moins de cycles étaient gaspillés à tourner en rond.

Faits intéressants et contexte historique (court, concret)

Le pipeline de NetBurst était notoirement profond (les générations Pentium 4 variaient), augmentant le coût des branches mal prédites et des flushs de pipeline.
Le Pentium D était essentiellement deux cœurs NetBurst empaquetés ensemble, amplifiant souvent la contention du front-side bus sous charge multithread.
La lignée Core s’appuie fortement sur la philosophie P6 d’Intel (ère Pentium Pro/II/III) : conception équilibrée, travail par cycle renforcé.
Core est arrivé d’abord sur mobile, où la puissance et la thermique ne sont pas négociables ; cette discipline s’est reportée aux serveurs.
Core 2 a fait de la « performance par watt » une métrique de conseil d’administration pour l’achat x86, pas seulement un argument pour l’autonomie des portables.
De nombreux designs Core 2 utilisaient un L2 partagé, réduisant certains trafics inter-cœurs comparé à des caches séparés en lutte pour le bus.
Le marketing d’Intel a pivoté des GHz vers la marque « Core » parce que la fréquence a cessé d’être un bon proxy de performance.
Le TDP est devenu central pour l’exploitation : la planification de densité en rack a de plus en plus utilisé les watts comme contrainte de premier ordre.

Ce que cela a changé pour le travail opérationnel réel

Les changements d’architecture ne sont pas des anecdotes. Ils modifient quels mythes de performance survivent. NetBurst a entraîné des organisations à acheter des « horloges plus rapides » puis à se demander pourquoi le système se bloque encore. Core/Core 2 a forcé un nouveau modèle mental : la performance CPU est une propriété système — front-end, exécution, caches, mémoire et gestion de la puissance comptent tous.

Latence : pourquoi Core 2 semblait « plus réactif » même avec des horloges plus basses

Les équipes ops voient souvent deux systèmes avec un « %CPU » similaire se comporter complètement différemment sous charge. L’un a un p99 stable. L’autre s’effondre en une falaise de latence. Avec le comportement de l’ère NetBurst, pipelines profonds et IPC plus bas signifiaient que de petites inefficacités se transformaient en délais d’attente plus importants. Core 2 n’a pas éliminé les falaises, mais il les a déplacées plus loin et a rendu la pente moins abrupte.

Puissance et thermique : moins de ralentissements invisibles

Le throttling thermique est un bug de performance qui ne s’affiche pas dans votre revue de code. Sous NetBurst, il était plus facile d’atteindre les limites thermiques, surtout dans des racks denses ou des courbes de ventilateurs mal ajustées. Avec l’efficacité de Core 2, les mêmes conditions ambiantes déclenchaient moins souvent des mystères « même SKU, vitesse différente ».

Virtualisation et consolidation : l’ère du « on en met plus sur moins de machines »

Core 2 a coïncidé avec une vague de consolidation. Mais la consolidation ne fonctionne que lorsque le CPU se comporte de façon prévisible sous des charges mixtes. Un IPC meilleur, une meilleure efficacité et un comportement de cache amélioré ont rendu plus réaliste le fait de mettre plusieurs services sur un même hôte sans transformer chaque pic en incident.

Une citation d’ingénierie (idée paraphrasée)

L’espoir n’est pas une stratégie — attribuée dans la culture ops au général Gordon R. Sullivan. Traitez la planification de capacité CPU de la même façon : mesurez, ne rêvez pas.

Playbook de diagnostic rapide : trouver le goulot d’étranglement vite

Voici l’ordre qui vous empêche de perdre une heure à vous disputer devant des graphes. L’objectif est de répondre : « Est-ce le CPU, la mémoire, la contention du scheduler ou autre chose qui se fait passer pour un problème CPU ? »

Première étape : confirmez quel type de « lent » vous avez

Est-ce la latence (p95/p99) ou le débit (requêtes/sec) ? Les problèmes de latence se cachent souvent derrière un « CPU à seulement 40% ».
Vérifiez la file d’exécution et le steal time. Si vous êtes virtualisé, le « %CPU » peut mentir.
Contrôlez la fréquence et le throttling. Un CPU bloqué sur de basses horloges se comporte comme un CPU lent, pas comme un CPU occupé.

Deuxième étape : déterminez si le CPU fait un travail utile

Fort %user ? Probablement du calcul applicatif ou crypto/compression.
Fort %system ? Surcharge du noyau : réseau, stockage, changements de contexte, contention sur des verrous.
Fort iowait ? Le CPU attend ; le goulot est le stockage ou quelque chose en aval.

Troisième étape : décidez si c’est calcul, mémoire ou contention

Limité par le calcul : forte utilisation IPC, hotspots dans perf, horloges stables.
Limité par la mémoire : nombreux ratés de cache, cycles bloqués, peu d’instructions retraitées par rapport aux cycles.
Limité par la contention : fortes commutations de contexte, contention sur les verrous, pics de file d’exécution, voisins bruyants.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici des commandes Linux exécutables qui vous aident à diagnostiquer les goulots CPU en production. Chaque tâche indique ce que la sortie signifie et quelle décision prendre.

Task 1: Identify the CPU family and model (and infer era)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|Vendor|MHz'
Vendor ID:                            GenuineIntel
Model name:                           Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz
CPU(s):                               8
Thread(s) per core:                   1
Core(s) per socket:                   4
Socket(s):                            2
CPU MHz:                              2660.000

Signification : Les noms de modèle comme « E5xxx » suggèrent des Xeon de l’ère Core 2. Un thread par cœur indique l’absence d’Hyper-Threading sur ce SKU (ou désactivé). Le CPU MHz affiché peut être la fréquence courante, pas la maximale.

Décision : Si vous observez des symptômes d’IPC bas sur un système NetBurst, la mise à niveau n’est pas « agréable à avoir ». Si vous êtes sur un silicium de l’ère Core 2, concentrez-vous d’abord sur la mémoire/le bus et les états d’alimentation avant d’accuser le « CPU ancien ».

Task 2: Check current frequency and governor (throttling suspicion)

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

Signification : Un serveur bloqué en powersave peut maintenir une fréquence basse, créant des pics de latence sous charge par à-coups.

Décision : Envisagez le gouverneur performance pour les couches sensibles à la latence, ou ajustez selon le budget énergétique si nécessaire.

Task 3: Validate actual frequency under load (not just “policy”)

cr0x@server:~$ grep -E 'cpu MHz' /proc/cpuinfo | head -4
cpu MHz		: 1596.000
cpu MHz		: 1596.000
cpu MHz		: 1596.000
cpu MHz		: 1596.000

Signification : Si un CPU 2.66GHz tourne à ~1.6GHz pendant le trafic, soit le gouverneur est conservateur, soit vous êtes en throttling puissance/thermique.

Décision : Si la latence tail compte, corrigez le comportement de fréquence avant de réécrire le code. Sinon vous optimisez sur du sable.

Task 4: Quick “is it CPU, iowait, or steal?” snapshot

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

11:21:10 AM  CPU   %usr  %nice  %sys  %iowait  %irq  %soft  %steal  %idle
11:21:11 AM  all   62.10  0.00   8.20  0.30    0.00  1.10   0.00    28.30
11:21:11 AM    0   84.00  0.00   6.00  0.00    0.00  0.00   0.00    10.00
11:21:11 AM    1   81.00  0.00   7.00  0.00    0.00  0.00   0.00    12.00
11:21:11 AM    2   14.00  0.00   6.00  0.00    0.00  0.00   0.00    80.00
11:21:11 AM    3   12.00  0.00   5.00  0.00    0.00  0.00   0.00    83.00

Signification : Globalement le CPU est occupé en espace utilisateur ; certains cœurs sont fortement chargés tandis que d’autres sont inactifs. Cela peut être des goulots mono-thread, de l’affinité, ou un déséquilibre de file d’exécution.

Décision : Cherchez l’affinité des threads, un processus chaud unique, ou des verrous. N’« ajoutez pas de cœurs » tant que vous n’avez pas prouvé que la charge scale.

Task 5: Check run queue and load relative to cores

cr0x@server:~$ uptime
 11:21:40 up 23 days,  4:18,  2 users,  load average: 12.40, 10.10, 8.50

Signification : Une charge moyenne au-dessus du nombre de CPU (8) suggère de l’exécution en file ou des tâches en sommeil non interruptible (souvent I/O). Ici elle est clairement supérieure à 8.

Décision : Si %iowait est bas mais la charge est haute, suspectez la contention sur les verrous ou trop de threads exécutables ; si %iowait est élevé, suspectez le stockage.

Task 6: Spot context switch storms (contention smell)

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
12  0      0  82136  10240 512000    0    0     1     3 2200 48000 62  8 28  1  0
11  0      0  82040  10240 512040    0    0     0     0 2100 51000 63  7 29  1  0
13  0      0  81980  10240 512120    0    0     0     0 2150 53000 61  8 29  1  0

Signification : Un cs élevé (commutations de contexte) suggère de la contention, trop de threads ou des réveils fréquents. Un r élevé corrobore la mise en file d’exécution.

Décision : Analysez les pools de threads, les hotspots de verrous et le comportement du scheduler. Core 2 vs NetBurst ne réparera pas une appli qui se massacre en commutations de contexte.

Task 7: Identify top CPU consumers immediately

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
 24831 java            380.5 12.1
  1142 irq/24-eth0       85.0  0.0
  9876 postgres          72.1  4.2
  2210 ksoftirqd/1       40.3  0.0
  3333 nginx             18.0  0.3

Signification : Un seul processus Java consommant ~380% sur une machine 8 cœurs suggère du multi-thread compute. Des threads IRQ et softirq élevés suggèrent une surcharge réseau ou un déséquilibre d’interruptions.

Décision : Si les threads IRQ sont élevés, ajustez l’affinité IRQ et les offloads NIC. Si un processus domine, profilez-le plutôt que de « tuner le noyau » d’emblée.

Task 8: Look for interrupt imbalance (classic “one core pegged”)

cr0x@server:~$ cat /proc/interrupts | head -10
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
 24:    9823412      12034      11022      10987      10221       9987       9876      10002  IR-PCI-MSI  eth0

Signification : Les interruptions eth0 arrivent presque entièrement sur CPU0. Ce cœur devient votre goulet accidentel.

Décision : Corrigez la distribution des IRQ (irqbalance ou affinité manuelle). C’est particulièrement important sur les plateformes plus anciennes où la saturation d’un seul cœur arrive plus vite.

Task 9: Confirm C-states and possible latency impact

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
POLL
C1
C2
C3

Signification : Les états C profonds économisent de l’énergie mais ajoutent une latence de réveil. Les systèmes Core/Core 2 avec gestion d’énergie agressive peuvent vous surprendre sous trafic par à-coups.

Décision : Pour les services ultra-faible latence, envisagez de restreindre les états C profonds via les paramètres du noyau ou le BIOS. Mesurez avant et après ; ne faites pas du cargo-cult.

Task 10: Validate memory pressure vs CPU pressure

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           16000       15200         120         180         680         420
Swap:           2048        1100         948

Signification : Peu de mémoire disponible et du swap utilisé peuvent transformer un « problème CPU » en catastrophe de pagination. Le CPU semble occupé parce qu’il gère des ratés de cache et des stalls mémoire.

Décision : Arrêtez-vous et traitez la mémoire d’abord : réduisez le working set, ajustez les caches, ajoutez de la RAM ou isolez la charge. Un cœur plus rapide ne rattrapera pas le paging.

Task 11: See if storage latency is the real culprit (iowait lies sometimes)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          55.20    0.00    8.10    6.70    0.00   30.00

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         120.0   220.0  6400.0 11200.0     76.5     8.20   23.10    18.00    26.20   0.80  28.0

Signification : await autour de ~23ms n’est pas excellent pour des attentes NVMe. La profondeur de file est élevée. Même si le CPU est « occupé », la latence stockage peut brider la progression.

Décision : Analysez le chemin de stockage : système de fichiers, RAID, contrôleur, saturation, jobs en arrière-plan. N’accusez pas la génération CPU pour une file disque.

Task 12: Capture top kernel/user hotspots with perf

cr0x@server:~$ sudo perf top -g --stdio --delay 2 --count 5
Samples: 5K of event 'cpu-clock:pppH', Event count (approx.): 1250000000
  18.20%  java            libjvm.so             [.] G1ScanRSForRegion
  12.10%  java            libjvm.so             [.] Unsafe_CopyMemory
   9.50%  vmlinuz         [kernel.kallsyms]     [k] tcp_recvmsg
   7.80%  vmlinuz         [kernel.kallsyms]     [k] __memcpy
   6.40%  postgres        postgres              [.] ExecHashJoin

Signification : Vous avez de vrais symboles : scan du garbage collector, copie mémoire unsafe, chemin TCP receive et un hash join de base de données. C’est exploitable.

Décision : Si les hotspots sont memcopy/GC, vous êtes probablement limité en bande passante mémoire ; pensez à régler l’allocateur/GC, le batching et la disposition des données. Si le TCP noyau domine, examinez le tuning du réseau, le débit de paquets et les offloads.

Task 13: Detect CPU throttling from thermal/power constraints

cr0x@server:~$ sudo dmesg | egrep -i 'thermal|throttl|powercap' | tail -6
[102938.112] CPU0: Core temperature above threshold, cpu clock throttled
[102938.113] CPU0: Core temperature/speed normal

Signification : Vous avez une preuve de throttling. Même des événements brefs peuvent créer des pics de latence tail et des performances de nœud inégales.

Décision : Corrigez le flux d’air, les dissipateurs, les limites BIOS de puissance, les courbes de ventilateur, la poussière (oui), et le placement en rack. Ce n’est pas un bug logiciel.

Task 14: Check if virtualization is stealing your cycles

cr0x@server:~$ mpstat 1 2 | tail -2
Average:     all   44.50    0.00    6.00    0.20    0.00    0.70   18.30   30.30

Signification : %steal ~18% signifie que l’hyperviseur vous dit : « vous vouliez du CPU, mais quelqu’un d’autre l’a obtenu. »

Décision : Déplacez la VM, ajustez shares/limits, ou réservez du CPU. Ne touchez pas au dimensionnement des threads applicatifs tant que vous perdez des cycles par steal.

Trois mini-histoires du monde de l’entreprise

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

Une entreprise de taille moyenne exécutait un pipeline d’analyse client sur une flotte mixte. Certains nœuds étaient des Pentium D « anciens mais suffisants » qui avaient survécu à plusieurs cycles de renouvellement parce qu’ils « avaient encore deux cœurs ». L’hypothèse de l’équipe était simple : deux cœurs = deux cœurs, le job est batch, peu importe.

Puis le pipeline a été étendu pour gérer des flux quasi temps réel. Même code, même ordonnanceur de cluster, juste des délais plus serrés. Du jour au lendemain, le système a commencé à rater des fenêtres de traitement. L’astreinte voyait le CPU à fond et a supposé un problème de capacité : ajouter des workers.

Ils ont ajouté des workers. Les choses ont empiré. L’ordonnanceur a placé plus de tâches sur les nœuds Pentium D parce qu’ils étaient « disponibles », et ces nœuds sont devenus l’évier de performance du cluster. Les étapes gourmandes en mémoire se sont accumulées sur le front-side bus partagé. Les commutations de contexte ont augmenté. Les autres nœuds attendaient des retardataires. La latence tail du pipeline n’était pas une régression logicielle ; c’était un frein architectural.

La correction n’était pas élégante : isoler les nœuds de l’ère NetBurst pour tout ce qui est temps-sensible, puis les décommissionner. La leçon a survécu : la planification de capacité doit traiter la capacité par cœur comme une métrique de première classe, pas comme une pensée après coup. Un « cœur » n’est pas une unité normalisée entre générations.

Mini-histoire 2 : L’optimisation qui a fait marche arrière

Un service proche du trading voulait une latence plus faible. Quelqu’un a remarqué que leur gouverneur CPU n’était pas réglé sur performance sur un ensemble de serveurs Core 2. Ils l’ont changé sur toute la flotte et ont obtenu une belle amélioration du p99 le premier jour. On a fêté la victoire.

La deuxième semaine, l’équipe du datacenter a ouvert un ticket : une rangée chauffait plus que prévu. Rien n’était « down », mais les températures d’entrée étaient en hausse et le système de refroidissement travaillait plus. Puis la partie étrange : la latence a commencé à empirer pendant les heures de pointe, même si les horloges étaient « maxées ».

Ils ont fini par corréler les événements : les serveurs consommaient désormais plus d’énergie en permanence. Cette rangée atteignait plus souvent les seuils thermiques, provoquant de courts événements de throttling. Ces événements étaient trop brefs pour apparaître dans les graphes CPU moyens mais assez longs pour créer des pics de latence tail sous charge par à-coups.

Ils ont annulé le changement massif et l’ont fait correctement : appliquer le gouverneur performance seulement sur les nœuds critiques pour la latence, plafonner le turbo/boost quand nécessaire, et corriger le flux d’air/panneaux de blindage. L’« optimisation » était réelle, mais le déploiement était imprudent. En termes SRE : vous avez amélioré un SLI en dégradant un SLI non mesuré (marge thermique) jusqu’à ce que cela vous morde.

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

Un fournisseur SaaS avait l’habitude qui semblait douloureusement inintéressante : chaque génération matérielle recevait une petite piscine canari avec des images OS identiques et la même charge de production rejouée chaque nuit. Pas de héros, juste des mesures répétables.

Lorsqu’ils ont évalué un renouvellement depuis des restes d’ère NetBurst vers des serveurs basés sur Core 2 pour une couche secondaire, les résultats canari ont montré quelque chose d’inattendu : le débit augmentait modestement, mais le grand gain était la stabilité de la latence tail sous des charges mixtes. Les graphes n’étaient pas spectaculaires ; ils étaient calmes. Le calme n’a pas de prix.

Des mois plus tard, une mise à jour du noyau a introduit une régression pour un pattern réseau particulier. La piscine canari l’a détectée avant le déploiement large. Parce qu’ils avaient un comportement de référence par génération CPU, l’équipe a pu séparer « régression noyau » de « variabilité du CPU ancien » en quelques heures. Pas de devinettes, pas de reproches.

Ils ont rollback le noyau, épinglé les versions pour cette couche et planifié un retest contrôlé. La pratique qui les a sauvés n’était pas un drapeau de tuning magique. C’était la discipline des baselines et des canaris, appliquée de façon cohérente à travers les générations matérielles.

Erreurs courantes : symptôme → cause racine → correction

Symptôme : « Le CPU est à seulement 40% mais la latence p99 est catastrophique. »
Cause racine : Goulot mono-thread, déséquilibre d’IRQ, ou scaling de fréquence maintenant des horloges basses.
Correction : Vérifiez l’utilisation par cœur (mpstat -P ALL), les interruptions (/proc/interrupts) et le gouverneur/fréquence. Équilibrez les IRQ ; augmentez les horloges pour les couches latence-sensibles ; profilez le thread chaud.
Symptôme : Deux serveurs identiques se comportent différemment sous la même charge.
Cause racine : Throttling thermique, réglages BIOS différents, ou comportement firmware en arrière-plan.
Correction : Vérifiez dmesg pour le throttling, comparez les configs BIOS, vérifiez les courbes de ventilateur et les températures d’entrée. Traitez les thermiques comme une dépendance de production.
Symptôme : Ajouter des threads de workers réduit le débit.
Cause racine : Contention et commutations de contexte ; pression sur le front-side bus et sur les caches (surtout sur les architectures anciennes).
Correction : Réduisez le nombre de threads, utilisez le batching, mesurez la contention de verrous, profilez. Sur matériel legacy, préférez moins de threads occupés plutôt que beaucoup de threads exécutables.
Symptôme : Forte %sys et threads softirq monopolisant un cœur.
Cause racine : Débit de paquets trop élevé, déséquilibre d’affinité d’interruptions, ou chemin réseau inefficace.
Correction : Distribuez les IRQ, envisagez RSS, revoyez les offloads NIC, et réduisez le taux de paquets (batching, choix MTU) quand c’est possible.
Symptôme : « La mise à niveau CPU n’a pas aidé la latence de la base de données. »
Cause racine : Latence stockage ou pression mémoire dominante ; le CPU n’a jamais été le goulot.
Correction : Utilisez iostat -xz, vérifiez free -m, et profilez les plans de requête. Mettez à niveau le stockage et la mémoire avant d’ajouter des cœurs.
Symptôme : Charge moyenne élevée avec %usr bas et %sys bas.
Cause racine : Tâches bloquées en sommeil non interruptible (souvent I/O), ou blocages noyau.
Correction : Inspectez vmstat pour les tâches bloquées (b), lancez iostat, et enquêtez sur le stockage/services en aval.

Listes de contrôle / plan étape par étape

Lorsque vous héritez d’une flotte qui va de NetBurst à l’ère Core 2

Inventoriez les modèles CPU (lscpu) et groupez par génération d’architecture. Ne traitez pas le « nombre de cœurs » comme une unité normalisée.
Baselinez le comportement de fréquence (gouverneur + MHz observés). Si les horloges varient de façon imprévisible, vos graphes vous mentent.
Baselinez la latence tail sous charge mixte. Les tests axés uniquement sur le débit cachent la douleur.
Identifiez les goulets partagés : contention front-side bus, bande passante mémoire, routage des interruptions, latence stockage.
Définissez la politique d’ordonnancement : gardez les charges sensibles à la latence et à la mémoire hors des nœuds les plus faibles/variables.
Décidez des critères de décommission : tout nœud qui throttle fréquemment ou provoque des stragglers est retiré des pools critiques.

Quand la performance régresse après un changement « simple » lié au CPU

Vérifiez d’abord les horloges et le throttling (gouverneur, /proc/cpuinfo, dmesg).
Vérifiez le steal time si virtualisé (mpstat).
Vérifiez la distribution des IRQ (/proc/interrupts).
Profilez les hotspots (perf top) et décidez si c’est calcul, mémoire ou overhead noyau.
Rollback si vous ne pouvez pas expliquer le changement. La production n’est pas une foire scientifique.

Achat et planification de capacité (la partie ennuyeuse qui évite les incidents)

Mesurez la performance par watt pour votre charge, pas un benchmark fournisseur.
Utilisez la latence tail comme KPI d’acceptation dans les tests.
Standardisez les réglages BIOS et d’alimentation au sein d’un pool ; la dérive devient une « performance mystérieuse ».
Planifiez de la marge de refroidissement. Un CPU qui throttle est un CPU que vous n’avez pas acheté.

FAQ

1) Pourquoi NetBurst peinait-il dans les charges serveur comparé à Core/Core 2 ?

Les serveurs ont beaucoup de branches, sont sensibles à la latence mémoire et exécutent des charges mixtes. Le pipeline profond et la consommation de NetBurst rendaient ces réalités coûteuses. Core/Core 2 a amélioré l’IPC et l’efficacité, de sorte que la même charge gaspillait moins de cycles et atteignait moins souvent les limites thermiques.

2) L’« IPC » est-il réellement mesurable en production ?

Pas comme un unique chiffre avec les outils basiques, mais vous pouvez l’inférer via le profilage et les compteurs matériels. Pratiquement : si perf montre des stalls, des ratés de cache et beaucoup de cycles en memcopy/GC, vous êtes probablement limité par la mémoire. Si les hotspots sont compute-heavy avec des horloges stables, vous êtes plutôt calcul-bound.

3) Core 2 a-t-il complètement résolu le problème du front-side bus ?

Non. Core 2 dépendait encore du front-side bus à cette époque ; le grand changement vers les contrôleurs mémoire intégrés est venu plus tard. Mais Core 2 a amélioré l’efficacité du cœur et le comportement des caches, réduisant la douleur et retardant la saturation.

4) Pourquoi les vieilles machines Pentium D deviennent-elles des « stragglers » dans des jobs distribués ?

Parce que les systèmes distribués sont souvent limités par les travailleurs les plus lents. Un IPC plus faible, la contention du bus et des taux de stall plus élevés font que certains nœuds finissent systématiquement en retard. La queue tail de votre job devient l’horaire de votre job.

5) Dois-je mettre le gouverneur CPU sur performance partout ?

Non. Faites-le là où la latence compte et où vous avez de la marge thermique/énergétique. Les changements globaux peuvent déclencher du throttling et effacer vos gains. Mesurez le p99 et vérifiez les événements de throttling.

6) Pourquoi un cœur est-il souvent à 100% alors que les autres sont inactifs ?

Causes courantes : goulot mono-thread, contention par verrou qui sérialise le travail, ou routage d’interruptions qui déverse le travail sur un seul CPU. Vérifiez mpstat -P ALL, ps et /proc/interrupts.

7) Quelle est la différence pratique entre « CPU élevé » et « load average élevé » ?

Un CPU élevé signifie que vous brûlez des cycles. Une load average élevée signifie que des tâches attendent pour s’exécuter ou sont bloquées de façon non interruptible (souvent I/O). Vous pouvez avoir une charge élevée avec un CPU modéré quand le système est bloqué sur le stockage ou la contention.

8) Comment les leçons Core/Core 2 s’appliquent-elles aux CPU modernes ?

Le thème se répète : l’efficacité et la prévisibilité gagnent. Les pipelines profonds, les limites de puissance et les stalls mémoire existent toujours, simplement sous de nouveaux noms (comportement turbo, power caps, hiérarchies de cache, NUMA). Diagnostiquez le système, pas l’étiquette marketing.

9) Quel est le signe le plus rapide que vous êtes limité par la mémoire, pas par le CPU ?

Hotspots en memcopy/GC, performance qui n’améliore pas avec plus de threads, et symptômes comme une forte pression sur les caches. En pratique : perf top montrant des mouvements mémoire et des routines de copie noyau est un fort indice.

10) Retirer du matériel de l’ère NetBurst est-il toujours optionnel ?

Si c’est sur un chemin critique : non. Vous pouvez l’isoler pour du batch non critique, mais les pools mixtes génèrent de la dette opérationnelle. Votre « capacité bon marché » devient le passe-temps préféré de votre pager.

Petite blague #2 : Si vous discutez encore des GHz en 2026, j’ai une pile de CD AOL qui « venait avec l’internet gratuit ».

Conclusion : que faire ensuite

Le passage d’Intel de NetBurst à Core/Core 2 n’a pas été une évolution douce : c’était une correction. Pour les opérateurs, la leçon n’est pas la nostalgie de Conroe. C’est la discipline de traiter la performance CPU comme un comportement système complet : horloges, thermiques, caches, chemins mémoire, interruptions et contention.

Étapes pratiques qui rapportent vite :

Segmentez votre flotte par génération CPU et cessez de supposer que les cœurs sont équivalents.
Adoptez l’ordre de diagnostic rapide : horloges/throttling → steal/file d’exécution → travail utile vs attente → profilez les hotspots.
Corrigez le déséquilibre des interruptions et la mauvaise configuration de fréquence avant de toucher au code applicatif.
Construisez des baselines et des canaris pour que les changements matériels et noyau cessent d’être « mystérieux ».
Décommissionnez le matériel straggler des pools critiques. Vous n’avez pas besoin de la nostalgie ; vous avez besoin d’une latence prévisible.