Le mur thermique : comment la physique a mis fin à l’histoire préférée du marketing

L’histoire qui a craqué : les GHz comme plan d’affaires

Pendant longtemps, l’industrie du matériel vendait une promesse simple : attendez six mois, achetez le CPU suivant, et votre logiciel devient plus rapide.
Cette histoire était excellente pour les achats et terrible pour la discipline d’ingénierie. Elle encourageait une forme de paresse : ne corrigez pas
l’algorithme, ne réduisez pas les allers-retours, ne regroupez pas, ne shardez pas soigneusement — laissez simplement « la loi de Moore » faire le travail.

Le problème est que la loi de Moore (nombre de transistors) n’a jamais garanti la fréquence d’horloge. Et même le nombre de transistors n’est pas
la grosse manchette que les gens imaginent. La réalité opérationnelle est bornée par la distribution d’alimentation, le refroidissement et la vitesse à laquelle
vous pouvez déplacer les données vers l’endroit où le calcul a lieu. Vous pouvez empaqueter beaucoup de transistors dans un petit die ; vous ne pouvez pas
empaqueter un flux de chaleur infini dans un dissipateur. La physique ne négocie pas. La finance tente, mais la physique gagne.

L’industrie a donc pivoté : plus de cœurs, vecteurs plus larges, caches plus profonds, accélérateurs spécialisés, et un comportement turbo agressif qui
est essentiellement une négociation sur puce entre température, puissance et temps. Vous obtenez encore des gains de performance, mais ils ne sont pas
automatiques. Il faut les mériter avec du parallélisme, de la localité et un réglage adapté à la charge de travail.

Traduction opérationnelle : si vous ne pouvez pas expliquer pourquoi votre service est rapide, vous ne pourrez pas le garder rapide.
« On a mis à niveau le type d’instance » n’est pas une stratégie de performance ; c’est un médicament temporaire avec des effets secondaires.

Ce qu’est réellement le mur thermique (et ce qu’il n’est pas)

Le mur thermique est la limite pratique où augmenter la fréquence et l’activité de commutation pousse la dissipation de puissance au-delà de ce que
vous pouvez évacuer — dans des contraintes de coût, taille, fiabilité et bruit. Au-delà de ce point, des fréquences plus élevées ne sont pas « difficiles »,
elles sont coûteuses : elles exigent une tension plus élevée, ce qui augmente la puissance dynamique, élève la température, accroît les fuites, ce qui
élève encore la température. C’est la partie où le graphe cesse d’être une ligne droite et commence à ressembler à une étiquette d’avertissement.

Le mur thermique n’est pas « les CPU sont devenus pires ». Les CPU sont devenus plus compliqués. Ils masquent la latence avec des caches, l’exécution hors ordre,
la prédiction de branchement, l’exécution spéculative et — quand tout va bien — le turbo. Mais ils sont ultimement contraints par :

• Puissance : combien de watts le package et la plateforme peuvent fournir sans déclencher des limites.
• Évacuation de la chaleur : à quelle vitesse vous pouvez déplacer la chaleur du silicium vers l’air ambiant (ou l’eau) sans griller quoi que ce soit.
• Énergie par travail utile : la spéculation gaspillée, les cache misses et les pipelines bloqués consomment de la puissance sans rien produire pour vous.
• Mouvement des données : la latence mémoire et I/O peut transformer un « CPU rapide » en un serveur cher qui attend.

Le mur n’est pas une falaise unique. C’est un paquet de plafonds. Votre charge de travail heurtera un plafond différent selon que vous êtes lié au CPU,
limité par la mémoire, branchy, favorable au vectoriel, intensif en I/O, ou simplement déployé dans un châssis dont le flux d’air a été conçu par quelqu’un
qui déteste les ventilateurs.

Une idée paraphrasée pertinente de Gene Kranz (directeur de vol Apollo) est : « L’échec n’est pas une option » (idée paraphrasée).
En termes SRE : vous n’avez pas le droit de faire comme si les thermiques n’étaient pas réels simplement parce que votre surveillance n’inclut pas la température.

La physique que vous ne pouvez pas externaliser

Notions de puissance : pourquoi la tension est le vilain

Un modèle simplifié pour la puissance dynamique CPU est : P ≈ C × V² × f, où C est la capacité de commutation effective,
V la tension, et f la fréquence. Vous pouvez discuter des détails, mais l’implication est stable :
augmenter la fréquence tend à nécessiter des hausses de tension, et la tension nuit deux fois.

C’est pourquoi « il suffit d’augmenter les fréquences » est mort. Passer de 3.5 GHz à 4.5 GHz n’est rarement un coût linéaire. C’est une taxe
énergétique et thermique qui se manifeste par :

• Plus de puissance package et de stress sur les VRM
• Des throttlings plus agressifs
• Une performance moins prévisible sous charge soutenue
• Un coût de refroidissement plus élevé (et plus de pannes de ventilateurs, et plus de plaintes pour le bruit)

Transfert de chaleur : le goulot le moins glamour

La chaleur doit voyager des transistors à travers le silicium, le spreader thermique, le matériau d’interface thermique, vers un dissipateur,
puis dans l’air et sortir du châssis. Chaque étape a une résistance. Vous pouvez l’améliorer, mais pas indéfiniment et pas sans frais.

Dans un data center, vous avez aussi des contraintes au niveau de la salle : température d’entrée, confinement allée chaude, capacité CRAC,
gestion du flux d’air, et le fait que « ce rack est OK » n’est pas identique à « ce serveur au milieu du rack est OK ».

Fuites : quand la chaleur crée plus de chaleur

À mesure que les transistors rétrécissent, les courants de fuite prennent plus d’importance. Les fuites augmentent avec la température.
Ainsi une température plus élevée provoque plus de fuites, ce qui augmente la puissance, ce qui augmente la température. C’est la boucle que vous
observez lorsqu’un CPU semble stable pendant une minute puis glisse vers un état throttlé après soak thermique.

Le secret sale : l’utilisation n’est pas la performance

Un cœur à 60 % d’utilisation peut toujours être le goulot d’étranglement s’il passe du temps bloqué sur la mémoire ou en concurrence sur des verrous.
Pendant ce temps, une pile de stockage peut être « correcte » en débit et pourtant massacrer la latence des queues. Le mur thermique a poussé les architectures
vers une performance opportuniste : rafales courtes à haute fréquence (turbo) et beaucoup de cœurs parallèles. Cela rend l’interprétation des métriques
plus difficile, pas plus facile.

Ce n’est pas un seul mur : thermique, puissance, mémoire et le « les fils sont lents »

Le mur de la puissance : des limites plateforme que vous ne pouvez pas souhaiter loin

Même si votre CPU pouvait fonctionner à une puissance plus élevée, la plateforme pourrait ne pas. Les VRM de la carte mère, la capacité de l’alimentation
et les budgets de puissance du rack contraignent ce qui est possible. Les instances cloud cachent cela, mais ne l’enlèvent pas — votre « voisin bruyant »
est parfois la plateforme qui applique sa propre politique de puissance.

Le mur mémoire : les cœurs sont devenus plus rapides ; la mémoire n’a pas suivi

Le débit de calcul CPU a augmenté plus vite que la latence DRAM n’a diminué. Vous pouvez ajouter des canaux et de la bande passante, mais la latence
ne chute pas comme les gens l’attendent. Si votre charge est très miss-cache, plus de GHz n’aide pas beaucoup — votre CPU attend la mémoire.

C’est pourquoi les caches ont grossi et pourquoi la localité est devenue la manière adulte d’obtenir de la performance. C’est aussi pourquoi « ajoutez des cœurs »
peut se retourner contre vous : plus de cœurs partagent la bande passante mémoire et le cache de dernier niveau. À un moment, vous ajoutez des personnes qui font la queue
pour la même cuisine.

Le mur interconnexion / délai des fils : la distance compte aussi sur la puce

Les transistors sont devenus petits, mais les fils ne sont pas devenus instantanés. La propagation du signal, la complexité du routage et la distribution de l’horloge
deviennent des contraintes. Les grands designs monolithiques et haute fréquence sont douloureux à synchroniser et alimenter.

Le mur I/O : stockage et réseau peuvent être votre source de chaleur cachée

Les charges I/O-intensives ne sont pas « gratuites » parce qu’elles ne sont « pas CPU ». Elles provoquent des interruptions, des changements de contexte, du travail noyau,
du chiffrement, des sommes de contrôle et des copies mémoire. Cela consomme de la puissance et chauffe les CPU pendant que votre appli attend techniquement.

Les ingénieurs stockage voient cela constamment : la latence augmente, la puissance package CPU augmente, le turbo devient moins stable, et soudain votre
« service lié CPU » est en fait lié aux files.

Faits et histoire qui expliquent le pivot

• Les vitesses d’horloge se sont largement stabilisées au milieu des années 2000 pour les CPU grand public ; les vendeurs ont préféré l’échelle multicœur plutôt que des GHz sans fin.
• Le « scaling de Dennard » a ralenti : l’ancienne hypothèse selon laquelle réduire les transistors réduirait la puissance par surface s’est effondrée, faisant de la densité de puissance la contrainte principale.
• L’ère NetBurst d’Intel mettait l’accent sur des fréquences élevées et des pipelines profonds ; l’industrie a ensuite favorisé des designs avec un meilleur rendement par watt.
• Le turbo boost est devenu courant : les CPU dépassent opportunément la fréquence de base lorsqu’il reste de la marge thermique/puissance, rendant la performance soutenue moins déterministe.
• Les caches de dernier niveau ont explosé en taille car les misses sont devenus trop coûteux par rapport au débit des cœurs.
• Les extensions SIMD/vectorielles se sont multipliées (SSE, AVX, etc.) pour obtenir plus de travail par cycle — au prix de pics de puissance et de réductions de fréquence sous usage vectoriel intensif.
• Les data centers ont commencé à se soucier du PUE comme métrique business, reflétant que l’évacuation de la chaleur est un coût opérationnel réel, pas une réflexion après coup.
• Les accélérateurs spécialisés ont crû (GPU, DPU, ASIC) parce que les cœurs généralistes ne peuvent pas tout faire efficacement à l’échelle dans des budgets de puissance limités.

Comment le mur thermique se manifeste en production

En production, vous ne verrez rarement une grande bannière « MUR THERMIQUE ». Vous verrez des symptômes indirects :

• La latence se dégrade sous charge soutenue, même si l’utilisation CPU n’augmente pas de façon spectaculaire.
• La performance diffère entre hôtes identiques parce que le flux d’air, la poussière, les courbes de ventilateurs ou le firmware diffèrent.
• Les tâches nocturnes tournent bien en hiver et ralentissent « mystérieusement » en été.
• Les benchmarks sont excellents pendant 30 secondes ; les charges réelles tournent pendant des heures et atteignent le heat soak.
• Ajouter des cœurs augmente le débit mais aggrave la latence de queue à cause de la contention mémoire et des effets d’ordonnancement.
• Un rack est OK ; un serveur ne l’est pas. Les points chauds sont localisés et cruels.

Quand vous heurtez le mur, la forme de la défaillance compte. Certaines charges se dégradent en douceur ; d’autres tombent d’un coup car elles sont sensibles à la latence
(contention de verrous, cycles de garbage collection, files de stockage, deadlines RPC).

Blague n°1 : Le marketing adore les chiffres « jusqu’à » parce que « jusqu’à » n’entre pas sur une slide. Votre pager, malheureusement, lit les petites lignes.

Feuille de route pour un diagnostic rapide

La façon la plus rapide de perdre une journée est de discuter « CPU vs stockage » sans preuve. Faites ceci à la place. L’objectif est d’identifier le limiteur dominant en 10–20 minutes
et de choisir la mesure suivante, pas de perfectionner votre théorie.

Première étape : confirmez si vous êtes throttlé ou plafonné

• Vérifiez les fréquences actuelles et max, l’état du turbo et les compteurs de throttling.
• Vérifiez les limites de puissance du package et si vous les atteignez (comportement PL1/PL2).
• Vérifiez les températures et le comportement des ventilateurs ; cherchez le heat soak.

Deuxième étape : séparez « occupé » de « bloqué »

• Regardez la pression sur la file d’exécution et les changements de contexte.
• Vérifiez les indicateurs de stalls mémoire (cache misses, cycles stalled) avec des outils d’échantillonnage.
• Vérifiez la contention de verrous et le temps noyau vs temps utilisateur.

Troisième étape : contrôlez les files et la latence I/O, pas seulement le débit

• Stockage : await par périphérique, utilisation et profondeur de file.
• Réseau : retransmissions, pertes et charge softirq.
• Système de fichiers : pression sur les pages sales, writeback et activité de swap.

Quatrième étape : vérifiez la topologie et la politique

• Placement NUMA, affinité IRQ, gouverneur CPU et limites de cgroup.
• Virtualisation ou contraintes de gestion d’énergie cloud.
• Différences de firmware (microcode, paramètres BIOS de puissance).

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

Voici les actions à mener quand les graphiques sont vagues et que la panne est réelle. Chaque tâche inclut : une commande, ce que signifie la sortie,
et la décision qui s’ensuit. Exécutez-les sur un hôte représentatif sous charge, pas sur un canari inactif.

Task 1: See if CPUs are throttling due to temperature

cr0x@server:~$ sudo dmesg -T | egrep -i 'thrott|thermal|PROCHOT' | tail -n 5
[Mon Jan  8 02:11:41 2026] CPU0: Core temperature above threshold, cpu clock throttled (total events = 17)
[Mon Jan  8 02:11:41 2026] CPU2: Core temperature above threshold, cpu clock throttled (total events = 17)
[Mon Jan  8 02:11:42 2026] CPU0: Package temperature above threshold, cpu clock throttled (total events = 9)

Signification : Le noyau vous indique que le CPU a atteint des seuils thermiques et a réduit la fréquence.
Décision : Arrêtez de débattre du logiciel en premier. Vérifiez le refroidissement, le flux d’air, les courbes de ventilateurs et les paramètres de puissance soutenue ; puis
relancez des tests de charge après avoir traité les thermiques.

Task 2: Read live frequencies and throttling counters (Intel)

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 5 --num_iterations 2
  Avg_MHz  Busy%  Bzy_MHz  TSC_MHz  CoreTmp  PkgTmp  PkgWatt  CorWatt  GFXWatt
    2870   62.14    4618     2600     92.0    95.0    188.4    142.7     0.0
    2555   63.02    4050     2600     96.0    99.0    205.1    153.2     0.0

Signification : Un Busy% élevé avec une Avg_MHz qui baisse et des températures en hausse suggèrent une pression thermique soutenue ; la puissance est élevée et augmente.
Décision : Si cet hôte est dans un rack chaud, corrigez d’abord le flux d’air. Si c’est généralisé, envisagez des limites de puissance, des profils de ventilateurs ou un remodelage de la charge (réduire l’intensité vectorielle, regrouper les I/O).

Task 3: Check CPU frequency policy and governor

cr0x@server:~$ sudo cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 5200 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 1200 MHz (asserted by call to hardware)

Signification : Vous êtes sur powersave ; sous certaines charges il peut ne pas monter rapidement ou être contraint par la politique de plateforme.
Décision : Pour des services sensibles à la latence, définissez performance (ou ajustez EPP) et mesurez puissance/thermiques ensuite. Ne faites pas cela à l’aveugle sur un châssis thermiquement contraint.

Task 4: Detect cgroup CPU caps masquerading as “thermal issues”

cr0x@server:~$ systemctl show --property=CPUQuota --property=CPUAccounting myservice.service
CPUAccounting=yes
CPUQuota=200%

Signification : Le service est plafonné à ~2 cœurs de temps CPU. Il peut sembler que le « CPU n’est pas saturé » alors que les requêtes font la queue.
Décision : Augmentez le quota ou scalez horizontalement. Si vous êtes limité par la puissance, les plafonds peuvent être intentionnels — alors il faut du travail d’efficacité, pas de l’illusion.

Task 5: Check run queue pressure and load vs cores

cr0x@server:~$ uptime
 02:14:10 up 41 days,  6:22,  2 users,  load average: 48.12, 44.90, 38.77

Signification : Une charge moyenne proche ou supérieure au nombre de threads CPU suggère un backlog exécutable ou une attente I/O contribuant.
Décision : Utilisez vmstat et pidstat pour séparer exécutable vs bloqué et identifier les processus en faute.

Task 6: Identify CPU saturation vs I/O wait 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
18  2      0 128432  64220 912340    0    0   120   980 8210 9920 42 14 33 11  0
22  5      0 121100  64180 905220    0    0    80  2100 9020 11020 38 12 29 21  0

Signification : Un wa non négligeable et des processus bloqués (b) indiquent des délais de stockage ou de système de fichiers.
Décision : Passez à iostat et regardez la latence par disque ; ne micro-optimisez pas le code pendant que le noyau attend une file de périphérique.

Task 7: Measure per-device latency and saturation

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   r_await w_await aqu-sz  %util
nvme0n1         120.0   980.0     1.20   18.40   7.90   96.5
nvme1n1         110.0   910.0     1.10   17.90   7.40   94.8

Signification : Un w_await élevé, un aqu-sz élevé et ~95 % de %util indiquent que les périphériques sont saturés et que les écritures font la queue.
Décision : Réduisez l’amplification d’écriture (batch, compression, tuning fs/zfs), ajoutez des périphériques ou déplacez les écritures chaudes ailleurs. Si ce sont « juste des logs », traitez les logs comme du trafic de production.

Task 8: Check filesystem writeback pressure (dirty throttling)

cr0x@server:~$ grep -E 'Dirty:|Writeback:' /proc/meminfo
Dirty:            184532 kB
Writeback:         81244 kB

Signification : Une mémoire dirty/writeback élevée suggère que le noyau pousse des écritures et peut throttler les écrivains.
Décision : Si votre appli est sensible à la latence, envisagez d’isoler les charges écriture-intensives, d’ajuster les ratios dirty, ou d’utiliser des pipelines asynchrones/buferisés avec rétro-pression.

Task 9: Detect swap activity (often a “memory wall” costume)

cr0x@server:~$ sar -W 1 3
Linux 6.5.0 (server) 	01/08/2026 	_x86_64_	(64 CPU)

02:15:01 AM  pswpin/s pswpout/s
02:15:02 AM      0.00     18.00
02:15:03 AM      0.00     22.00

Signification : Une activité de swap-out signifie que vous évincez des pages ; la latence peut exploser même si le CPU semble « correct ».
Décision : Corrigez d’abord la pression mémoire : réduisez le working set, ajustez les caches (app, JVM, ARC), ou ajoutez de la RAM. N’optimisez pas le CPU pendant qu’il y a du paging.

Task 10: Check NUMA placement and remote memory hits

cr0x@server:~$ numastat -p 12345
Per-node process memory usage (in MBs) for PID 12345 (myservice)
                           Node 0          Node 1           Total
                  --------------- --------------- ---------------
Private                  18240.32         1024.11        19264.43
Heap                      6144.00          512.00         6656.00
Stack                        64.00           64.00          128.00
Huge                         0.00            0.00            0.00

Signification : La majeure partie de la mémoire est sur le Node 0 ; si des threads tournent sur le Node 1 vous paierez la latence distante. C’est le mur mémoire au quotidien.
Décision : Pincez CPU et mémoire via numactl, corrigez l’affinité ou reconfigurez votre ordonnanceur. Les bugs NUMA sont des bugs de performance déguisés en hasard.

Task 11: Find top CPU consumers and whether they burn sys time

cr0x@server:~$ pidstat -u -p ALL 1 2 | head -n 12
02:16:10 AM   UID       PID    %usr %system  %CPU  Command
02:16:11 AM     0       842     1.00    12.00 13.00  ksoftirqd/12
02:16:11 AM  1001    12345    48.00     6.00 54.00  myservice
02:16:11 AM     0      2101     0.00     7.00  7.00  nvme_poll_wq

Signification : Un %system significatif et la présence de ksoftirqd peuvent indiquer une pression d’interruptions (réseau/stockage) plutôt qu’un pur calcul applicatif.
Décision : Vérifiez la distribution des IRQ, les réglages NIC/RSS, le polling stockage et les chemins de code riches en syscall. Parfois le « problème CPU » c’est que vous effectuez simplement du travail noyau.

Task 12: Inspect IRQ affinity and imbalance (hot CPU cores)

cr0x@server:~$ cat /proc/interrupts | head -n 8
           CPU0       CPU1       CPU2       CPU3
  24:   9182736        120        110         98   PCI-MSI 524288-edge      eth0-TxRx-0
  25:       220   8122331        140        115   PCI-MSI 524289-edge      eth0-TxRx-1
  26:       210        160   7341120        130   PCI-MSI 524290-edge      eth0-TxRx-2

Signification : Les interruptions sont réparties sur les CPUs, mais si vous voyez un CPU en prendre presque toutes, vous obtenez des cœurs chauds et du throttling sans une forte utilisation moyenne.
Décision : Corrigez l’affinité (irqbalance ou manuel), validez les files RSS, et évitez d’affecter toutes les IRQ au même nœud NUMA que vos threads les plus chauds à moins que ce soit voulu.

Task 13: Spot memory bandwidth saturation and cache miss pain (quick sample)

cr0x@server:~$ sudo perf stat -e cycles,instructions,cache-misses,LLC-load-misses -p 12345 -- sleep 10
 Performance counter stats for process id '12345':

     18,220,114,992      cycles
     10,002,332,110      instructions              #    0.55  insn per cycle
        82,110,442      cache-misses
        40,220,119      LLC-load-misses

      10.001201545 seconds time elapsed

Signification : Un IPC faible (instructions par cycle) plus beaucoup de LLC misses suggère que le CPU est bloqué sur la mémoire. C’est le mur mémoire, opérationnellement.
Décision : Améliorez la localité (structure de données, stratégie de cache), réduisez le pointer chasing, regroupez les requêtes ou déplacez les données chaudes vers des étages plus rapides. Acheter des cœurs plus rapides n’aidera pas beaucoup.

Task 14: Check ZFS ARC pressure if you run ZFS (storage meets memory wall)

cr0x@server:~$ sudo arc_summary | egrep -i 'ARC Size|ARC Target|Cache Hit Ratio' | head -n 6
ARC Size:                               32.0 GiB
ARC Target Size (Adaptive):             48.0 GiB
Cache Hit Ratio:                        71.2 %

Signification : Une taille ARC inférieure à la cible et un taux de hit médiocre peuvent signifier que vous êtes contraint en mémoire ; les lectures touchent plus souvent le disque, augmentant la latence et la charge CPU.
Décision : Allouez plus de RAM, ajustez les limites ARC ou repensez le working set. Ne privez pas l’ARC pour « sauver de la mémoire » puis vous étonnez que les disques soient occupés.

Task 15: Validate actual temperatures and fan control at the hardware level

cr0x@server:~$ sudo ipmitool sdr type Temperature | head -n 6
Inlet Temp       | 26 degrees C      | ok
CPU1 Temp        | 92 degrees C      | ok
CPU2 Temp        | 94 degrees C      | ok
Exhaust Temp     | 48 degrees C      | ok

Signification : L’entrée est raisonnable, les CPU sont chauds, l’extraction est élevée. Cela pointe vers un contact dissipateur, une courbe de ventilateur, des filtres obstrués ou un flux d’air insuffisant dans le châssis.
Décision : Inspectez le chemin physique : poussière, pannes de ventilateur, obstructions de câble. Si c’est une tendance de flotte, reconsidérez la disposition des racks et les températures d’entrée.

Task 16: Confirm power limits and package power reporting

cr0x@server:~$ sudo rdmsr -a 0x610 | head -n 2
00000000d0a8d0a8
00000000d0a8d0a8

Signification : Ce MSR encode les limites de puissance du package (PL1/PL2) sur de nombreux systèmes Intel ; l’hex brut nécessite décodage, mais la cohérence entre CPU suggère un plafond imposé par la plateforme.
Décision : Si la performance est plafonnée, vérifiez les paramètres BIOS/firmware et les outils fournisseur. Dans le cloud, acceptez-le et optimisez pour perf/watt plutôt que de courir après des GHz fantômes.

Blague n°2 : J’ai essayé d’overclocker un serveur une fois. Ça a marché jusqu’à ce que les lois de la thermodynamique déposent un ticket.

Trois mini-récits d’entreprise venus du mur

Mini-récit 1 : L’incident causé par une fausse hypothèse (benchmarks en rafale ≠ réalité soutenue)

Une entreprise SaaS de taille moyenne a migré une API sensible à la latence vers des instances optimisées compute plus récentes. Le benchmark du fournisseur avait l’air excellent.
Leur test interne aussi — parce qu’il a duré cinq minutes et a déclaré victoire.

En production, l’API a géré une montée en charge en milieu de journée puis s’est lentement dégradée pendant l’heure suivante. Le p99 a grimpé. Les retries ont amplifié le trafic.
L’autoscaler a ajouté des nœuds, mais les nouveaux nœuds ont connu la même dégradation, juste avec un coût total supérieur.

La mauvaise hypothèse : « Si le CPU est à 50–60 %, nous ne sommes pas liés au CPU. » En réalité, la puissance package soutenue a poussé les CPU vers une fréquence
plafonnée et throttlée. Leur service était « à moitié utilisé » parce qu’il passait du temps bloqué sur la mémoire et l’I/O noyau, tandis que le comportement turbo variait minute après minute.
La métrique d’utilisation était honnête ; le modèle mental ne l’était pas.

La correction fut ennuyeuse : ils ont étendu les tests de charge à au moins une heure, tracé la fréquence dans le temps, et ajouté des compteurs thermiques et de puissance à leurs dashboards.
Ils ont aussi ajusté le regroupement des requêtes et réduit les allocations par requête, diminuant la pression de cache. Résultat : meilleur p99 et consommation électrique moindre — le genre de résultat que personne ne met sur une slide mais que tout le monde veut à 02:13.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (vectorisation rencontre limites de puissance)

Une équipe pipeline a optimisé une boucle chaude en activant des instructions vectorielles plus agressives dans leurs flags de build. Sur un hôte unique,
le débit a bondi. L’ingénieur qui l’a fait méritait du crédit — localement.

En production, l’effet sur la flotte était différent. Sous une charge soutenue riche en vecteurs, les CPU ont réduit la fréquence pour rester dans les limites de puissance et de thermique.
Le code « plus rapide » a augmenté la puissance instantanée, déclenchant des réductions de fréquence, ce qui a réduit la performance des autres threads, y compris compression et gestion réseau.

Le symptôme était étrange : le débit bout en bout s’améliorait parfois, parfois empirait, et la latence queue pour des services non liés sur des nœuds partagés chutait.
L’équipe plateforme a vu plus d’événements thermiques et une hausse des vitesses de ventilateurs. L’équipe data a observé des KPI bruyants et a blâmé le réseau. Tout le monde avait moitié raison et était complètement agacé.

La résolution a été d’isoler la charge sur des nœuds mieux refroidis et de limiter l’intensité vectorielle pour les charges mixtes. Ils ont aussi ajouté de la télémétrie de puissance par nœud aux décisions d’ordonnancement.
L’optimisation n’était pas « mauvaise », elle dépendait du contexte, et le contexte était limité par la puissance. La physique ne se soucie pas de vos options de compilateur.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (planification capacité avec puissance et thermiques)

Une société de services financiers exploitait un cluster privé avec des SLO de latence stricts. Ils suivaient aussi un processus de changement strict que personne n’aimait :
baseline firmware, paramètres BIOS de puissance cohérents et audits thermiques trimestriels incluant l’ouverture des châssis et le nettoyage des filtres.

Lors d’une canicule, plusieurs data centers voisins ont signalé des problèmes de performance et des throttlings surprises. Cette entreprise a eu des soucis aussi — ventilateurs un peu plus rapides, températures d’entrée légèrement supérieures — mais aucun impact client.
Leurs systèmes sont restés dans la marge.

La différence n’était pas héroïque. C’était que leur modèle de capacité incluait des marges de puissance et de refroidissement, pas seulement des cœurs CPU et de la RAM.
Ils traitaient les « watts par rack » comme une ressource de première classe et gardaient suffisamment de marge thermique pour que le comportement turbo ne devienne pas un pari.

Le postmortem ressemblait à une checklist, pas à un thriller. C’est le point. Les systèmes les plus fiables sont rarement excitants ; ils sont simplement entretenus de façon implacable, presque offensivement.

Erreurs courantes : symptômes → cause racine → réparation

1) Symptom: latency climbs over 30–90 minutes of load

Cause racine : Heat soak mène à un throttling soutenu ; le turbo est bon tôt, mauvais plus tard.

Réparation : Lancez des tests de charge plus longs, surveillez fréquences et températures, améliorez le flux d’air/refroidissement, et considérez des limites de puissance qui gardent la performance stable.

2) Symptom: “CPU is only 50%” but queues explode

Cause racine : Les threads sont bloqués sur la mémoire (IPC faible) ou sur l’I/O ; l’utilisation n’est pas le débit.

Réparation : Utilisez perf stat pour les indicateurs de stall, iostat pour l’await des périphériques, et éliminez la contention (batching, localité, réduction des allocations).

3) Symptom: two identical hosts have different performance

Cause racine : Différences de firmware, pannes de ventilateur, poussière, températures d’entrée différentes ou limites de puissance distinctes.

Réparation : Imposer des baselines BIOS/microcode ; auditer les capteurs IPMI ; inspecter et nettoyer physiquement ; valider le flux d’air du rack.

4) Symptom: after “optimization,” power rises and throughput drops

Cause racine : Activité de commutation plus élevée (vectorisation, busy polling, threads supplémentaires) déclenche des limites de puissance ou des thermiques, réduisant la fréquence.

Réparation : Mesurez la puissance package et la fréquence sous charge soutenue ; envisagez de limiter les threads, réduire la largeur vectorielle, ou isoler les charges aux nœuds appropriés.

5) Symptom: storage looks “fast” on throughput but p99 is awful

Cause racine : Mise en file d’attente et amplification d’écriture ; le périphérique est saturé (%util élevé) et la latence explose.

Réparation : Concentrez-vous sur await/aqu-sz, réduisez les petites écritures aléatoires, ajoutez des périphériques ou changez le chemin d’écriture (batch, log-structured, async).

6) Symptom: random microbursts of latency with no clear CPU spike

Cause racine : Tempêtes d’interruptions, saturation softirq, ou déséquilibre de l’ordonnanceur provoquant des cœurs chauds.

Réparation : Vérifiez /proc/interrupts, ajustez l’affinité IRQ/RSS, envisagez isolcpus pour les périphériques bruyants, et validez le comportement de ksoftirqd.

7) Symptom: adding cores improves throughput but worsens tail latency

Cause racine : Bande passante mémoire partagée et contention de LLC ; plus de threads augmentent l’interférence.

Réparation : Limitez les threads, placement NUMA-aware, réduisez les données partagées chaudes et utilisez des limites de concurrence plutôt que du parallélisme illimité.

8) Symptom: cloud instances of same type behave inconsistently

Cause racine : Gestion d’énergie au niveau hôte, silicium/steppings sous-jacents différents, ou contention de puissance par un voisin bruyant.

Réparation : Pointez vers des hôtes dédiés quand nécessaire, mesurez la fréquence soutenue par instance, et concevez des SLO en supposant la variabilité.

Listes de vérification / plan pas à pas

Lorsque la performance chute après une mise à niveau matérielle

1. Comportement soutenu de référence : lancez un test de charge de 60–120 minutes ; enregistrez fréquence, température et puissance package dans le temps.
2. Vérifiez la politique : gouverneur CPU/EPP, paramètres turbo, profil BIOS de puissance et quotas cgroup.
3. Vérifiez les thermiques physiquement : températures entrée/extraction, RPM des ventilateurs, poussière, obstruction des câbles, assise du dissipateur.
4. Vérifiez le comportement mémoire : IPC, LLC misses, activité de swap, localité NUMA.
5. Vérifiez la mise en file I/O : await et utilisation par périphérique, writeback système de fichiers, retransmissions réseau.
6. Re-testez : ne changez qu’une variable majeure à la fois ; sinon vous « réparerez » par coïncidence.

Lorsque vous suspectez un throttling thermique dans une flotte

1. Choisissez trois hôtes : meilleur, moyen, pire.
2. Collectez : turbostat (ou équivalent), températures ipmitool, événements dmesg thermiques.
3. Comparez : Avg_MHz soutenue sous la même charge ; cherchez les différences de température et les plafonds de puissance.
4. Agissez : si c’est localisé, corrigez le flux d’air et la maintenance hardware ; si c’est systémique, reconsidérez les limites de puissance et le placement des workloads.

Lorsque vous avez besoin d’une latence prévisible (pas seulement la vitesse de pointe)

1. Privilégiez la stabilité plutôt que le pic : ajustez pour une fréquence cohérente plutôt que des gains turbo ponctuels.
2. Définissez des limites de concurrence : ne laissez pas un nombre illimité de requêtes parallèles créer de la contention mémoire et I/O.
3. Minimisez les cache misses : réduisez les allocations, améliorez la localité, évitez les chemins chauds avec beaucoup de pointeurs.
4. Rendez l’I/O ennuyeux : regroupez les écritures, appliquez de la rétro-pression et gardez les files de périphériques courtes.
5. Instrumentez les thermiques : traitez la température et les événements de throttling comme des signaux de production.

FAQ

1) Is the thermal wall the reason my single-thread performance stopped improving?

En grande partie, oui. Des fréquences plus élevées demandent une puissance (tension) disproportionnée et créent une densité de chaleur insoutenable. Les vendeurs ont déplacé les gains vers multicœurs, caches et spécialisations.

2) Why do benchmarks show great performance but production is slower?

Beaucoup de benchmarks sont courts et s’exécutent avant le heat soak. La production est soutenue, mixte, et sensible au throttling, aux stalls mémoire et à la mise en file I/O. Mesurez sur la durée.

3) If my CPU isn’t at 100%, can it still be the bottleneck?

Absolument. Vous pouvez être limité par la latence mémoire, des verrous ou l’I/O alors que l’utilisation CPU semble modérée. Regardez IPC, cache misses, run queue et await des périphériques.

4) Does “more cores” always help?

Non. Plus de cœurs peuvent augmenter la contention sur la bande passante mémoire et le cache LLC, et augmenter la puissance/chaleur, provoquant du throttling. Ajustez les cœurs selon la localité et la bande passante de la charge.

5) What’s the difference between thermal throttling and power limiting?

Le throttling thermique réagit aux seuils de température ; la limitation de puissance applique des plafonds de watts au package/plateforme (souvent PL1/PL2). Les deux réduisent la fréquence ; la réparation dépend de celui que vous atteignez.

6) How do turbo modes change the ops story?

Le turbo rend la performance opportuniste. Vous pouvez obtenir une haute fréquence brièvement, mais la performance soutenue dépend du refroidissement et de la marge de puissance. Considérez la « base clock » comme le chiffre honnête.

7) Can storage issues cause CPU heat and throttling?

Oui. Des taux I/O élevés peuvent provoquer des interruptions, du CPU noyau, du chiffrement/sommes de contrôle et des copies mémoire. Cela consomme de la puissance pendant que votre appli « attend », et peut déstabiliser le turbo.

8) What should I monitor to catch the thermal wall early?

Au minimum : fréquence soutenue par hôte, événements de throttling thermique, puissance package, températures entrée/extraction, et latence/profondeur de file I/O par périphérique. Ajoutez-les aux métriques p95/p99.

9) Is liquid cooling the solution?

C’est un outil, pas un remède. Le refroidissement liquide peut augmenter la marge et la densité, mais votre charge peut toujours atteindre des limites de puissance, des murs mémoire ou des contentions I/O. L’efficacité reste nécessaire.

10) What’s the most cost-effective performance fix in a power-limited environment?

Réduisez le travail gaspillé : améliorez la localité, coupez les allocations, regroupez l’I/O, limitez la concurrence et supprimez la contention de verrous. La performance par watt est le nouveau « GHz ».

Conclusion : que faire la semaine prochaine, pas la décennie prochaine

Le mur thermique n’a pas tué le progrès. Il a tué le fantasme selon lequel le progrès est automatique. Vos systèmes deviennent toujours plus rapides, mais seulement si
vous alignez le logiciel sur les contraintes : watts, chaleur, latence mémoire et mise en file I/O. L’histoire marketing était « la vitesse est gratuite ».
La vérité opérationnelle est « la vitesse se conçoit ».

Prochaines étapes pratiques :

• Ajoutez la fréquence soutenue, la température et les événements de throttling à vos dashboards standards d’hôtes.
• Prolongez les tests de performance pour inclure le heat soak. Si c’est moins de 30 minutes, c’est une démo, pas un test.
• Installez une habitude : quand la latence monte, vérifiez throttling et files avant de toucher au code.
• Pour le travail de débit, optimisez pour la performance par watt : localité, regroupement, moins de stalls, moins d’allers-retours noyau.
• Rendez les baselines de flotte ennuyeuses : paramètres BIOS cohérents, microcode, courbes de ventilateurs et maintenance physique.

Vous ne battez pas la physique. Vous en faites le budget, vous l’instrumentez et vous concevez autour. Ce n’est pas du pessimisme. C’est de la production.