Oublier l’autocollant du refroidisseur : la cause d’overchauffe la plus drôle

novembre 29, 2025 • février 3, 2026 • Lecture : 25 min • Views: 0

Cet article vous a aidé ?

Vous pouvez dépenser six chiffres en capacités de calcul, ajuster votre noyau, dimensionner vos niveaux de stockage, et quand même perdre un nœud à cause d’un problème qui a coûté exactement 0 $ à créer : un tout petit film plastique laissé sur la plaque froide du refroidisseur.

Le mode de défaillance est à la fois burlesque et brutal : la machine démarre, fonctionne « correctement », puis commence à brider, déclenchant des alarmes thermiques, dégradant les performances NVMe ou redémarrant sous charge. Le tableau de bord hurle. Votre pager hurle plus fort.

Pourquoi un autocollant sur le refroidisseur peut mettre la production à genoux

L’« autocollant du refroidisseur » est habituellement un film protecteur transparent sur la plaque froide d’un refroidisseur CPU (air ou AIO). Il est là pour garder le métal propre et sans rayures pendant le stockage. Il n’est pas là pour faire interface thermique. En fait, c’est une manière presque parfaite de transformer votre solution de refroidissement coûteuse en une expérience de conservation de chaleur.

Le transfert de chaleur du CPU vers le refroidisseur est une chaîne. Rompre un maillon, le reste n’a plus d’importance :

Die → IHS (chemin interne du package CPU, hors de votre contrôle).
IHS → pâte thermique (sous votre contrôle ; fine, uniforme, pas artistique).
Pâte thermique → plaque froide (sous votre contrôle ; contact métal propre).
Plaque froide → caloducs/radiateur (conception du refroidisseur).
Radiateur/ailettes → flux d’air (boîtier ou châssis, courbes de ventilateur, obstructions).

Un autocollant se glisse dans l’interface la plus importante : le contact plaque froide. Même si l’autocollant est « fin », il introduit une couche à faible conductivité thermique et piège souvent des micro-poches d’air. La pâte thermique ne règle pas le problème ; de la pâte sur du plastique, ce n’est que de la pâte en plus.

Sur une station de travail, cela devient « mon jeu saccade ». Sur un serveur, ça devient « mon nœud disparaît de façon intermittente » ou « les latences montent en flèche sous trafic de pointe », ou pire : « les reconstructions de stockage prennent une éternité, puis la machine redémarre. »

Une vérité sèche : la surchauffe est rarement une défaillance nette. C’est salissant. Ça se déguise en RAM instable, firmware bogué, voisins bruyants, saturation du stockage ou « Kubernetes qui est Kubernetes ».

Blague n°1 (court, pertinent) : L’autocollant du refroidisseur est le seul film de protection qui bloque la chaleur avec succès au lieu des hackers.

Feuille de route de diagnostic rapide (premier/deuxième/troisième)

Vous ne gagnez pas de points pour « analyse approfondie » pendant que la flotte grille. Vous gagnez des points pour rétablir le service et prévenir les incidents répétés. Voici un ordre de triage rapide qui trouve le goulot d’étranglement vite, avec un minimum d’agitation.

Premier : confirmer que c’est thermique, pas « juste lent »

Recherchez le throttling : la fréquence CPU chute sous charge, malgré une forte utilisation.
Vérifiez les températures : température du package CPU proche ou à TjMax ; températures GPU/NVMe élevées si pertinent.
Cherchez des événements thermiques : logs du kernel, IPMI SEL, alarmes capteurs BMC.

Deuxième : déterminer l’étendue et le rayon d’impact

Un seul nœud ou plusieurs ? Si plusieurs, suspectez le flux d’air ambiant, la politique de contrôle des ventilateurs, un déploiement de firmware ou des filtres colmatés.
Spécifique à une charge ? Seulement sous calcul AVX intense, compactage soutenu, reconstruction ou chiffrement ?
Corrélé dans le temps ? Même heure chaque jour peut être des jobs batch, mais aussi des horaires de gestion d’air ou des habitudes de porte de rack.

Troisième : décider du chemin de mitigation le plus sûr

Sécurité immédiate : réduire la charge, évacuer les workloads, limiter la puissance, augmenter la politique de vitesse des ventilateurs.
Vérification physique : si une nouvelle construction ou unité récemment entretenue, supposez une erreur d’installation jusqu’à preuve du contraire.
Correction permanente : nettoyer/remplacer les ventilateurs, remonter le refroidisseur, retirer l’autocollant, réappliquer la pâte, mettre à jour le firmware, ajuster le design du flux d’air.

Le chemin le plus rapide pour répondre « est-ce l’autocollant ? » est brutalement simple : si c’est une nouvelle construction, un échange de refroidisseur ou un reseating de CPU, et que vous voyez une surchauffe immédiate même sous charge modérée, traitez l’interface de la plaque froide comme suspecte jusqu’à preuve contraire.

Faits intéressants et un peu d’histoire

La surchauffe est ancienne. L’incident d’autocollant est plus récent que la plupart ne le pensent, et il est plus courant aujourd’hui parce que le bricolage et le déploiement rapide ont changé l’ergonomie du travail matériel. Quelques points concrets pour ancrer l’histoire :

Le throttling thermique n’est pas une invention moderne. Les CPU ont des formes de protection thermique depuis des décennies ; les puces modernes rendent ça juste plus dynamique et plus difficile à remarquer.
Les films protecteurs sont devenus plus courants à mesure que les refroidisseurs sont devenus des produits premium. Les plaques froides à finition miroir et les pâtes pré-appliquées sont expédiées avec des films pour éviter contamination et rayures.
La pâte n’est pas de la colle. Son rôle est de combler les vides microscopiques ; le contact métal-métal reste le chemin thermique principal.
Le contrôle des ventilateurs est passé de la tension brute à des courbes intelligentes. Le contrôle PWM et les politiques BMC peuvent masquer un mauvais contact en vous « sauvant » au repos et en échouant sous charge soutenue.
Les datacenters fonctionnent de plus en plus avec des températures d’entrée plus élevées. Les objectifs d’efficacité entraînent des allées plus chaudes ; la marge pour les petites erreurs diminue.
NVMe a apporté de nouveaux goulots thermiques. Les SSD modernes réduisent leur performance selon la température et peuvent ressembler à une « latence stockage » plutôt qu’à de la « chaleur ».
AVX et ensembles d’instructions similaires peuvent modifier le profil thermique. Le même CPU à la même utilisation peut chauffer beaucoup plus selon le mix d’instructions.
La gestion à distance a normalisé les opérations « sans les mains ». Les outils IPMI/BMC ont rendu facile d’oublier que certaines défaillances exigent des yeux et un tournevis.
Les pads thermiques sur les VRM et la mémoire existent pour une raison. Un mauvais alignement lors de l’assemblage peut surchauffer l’alimentation alors que le CPU semble normal, provoquant des réinitialisations étranges et des erreurs WHEA.

À quoi ça ressemble dans les logs, métriques et retours utilisateurs

La boulette de l’autocollant a une signature : les températures montent rapidement et tôt. Pas « après une heure », mais « en quelques minutes de toute charge réelle ». La courbe des ventilateurs atteint le maximum. Le CPU continue de surchauffer. Ce décalage — ventilateurs hurlants et températures qui montent malgré tout — est le signe révélateur.

Symptômes courants de surface

Redémarrages aléatoires sous charge (arrêt thermique ou protection VRM).
Pics soudains de latence (le CPU bride ; les files d’attente augmentent).
Résultats de benchmark incohérents (l’équilibre thermique change d’un run à l’autre).
« Le stockage est devenu lent » (le throttling NVMe rend la latence IO instable et les temps de compactage/reconstruction explosent).
Fréquence CPU bloquée basse malgré beaucoup de marge sur le papier.
Messages kernel sur les zones thermiques ou indices « CPU throttled ».
Alarmes capteurs IPMI (CPU Temp, VRM Temp, System Temp) ou événements SEL.

Ce qui se passe réellement

Quand le CPU atteint les limites thermiques, il ne demande pas poliment. Il change de comportement : réduit fréquence et tension, bride le turbo, applique parfois des limites de puissance, et si les températures continuent d’augmenter, déclenche un arrêt protecteur. Ces contrôles préservent le silicium. Ils ne préservent pas votre SLO.

En production, le throttling est particulièrement vicieux parce qu’il est non linéaire. Vous pouvez être correct à 55 % de charge, puis atteindre un point critique et chuter vertigineusement à 70 %. Votre planification de capacité semble correcte jusqu’au moment où ce n’est plus le cas.

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

Ce sont les contrôles que j’exécute réellement. Chaque tâche inclut : une commande, une sortie représentative, ce que ça signifie, et la décision que vous prenez. Vous pouvez faire la plupart de ces vérifications sans arrêter la machine — jusqu’au moment où il faudra le faire.

Task 1: Check current CPU frequencies (throttling hint)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|MHz'
Model name:                           Intel(R) Xeon(R) CPU
CPU(s):                               32
Thread(s) per core:                   2
CPU MHz:                              1197.843

Signification : Un CPU de classe serveur tournant autour de 1200 MHz au repos est normal ; c’est suspect sous charge.
Décision : Si les utilisateurs signalent une lenteur et que cela reste bas pendant la charge, recherchez le throttling ensuite.

Task 2: Watch frequency under load in real time

cr0x@server:~$ sudo apt-get -y install linux-tools-common linux-tools-generic >/dev/null
cr0x@server:~$ sudo turbostat --Summary --interval 2
turbostat version 2024.01
Summary: 2 sec
Avg_MHz   Busy%   Bzy_MHz  TSC_MHz  PkgTmp  PkgWatt
1680      92.15   1822     2300     97      182.4

Signification : Température package 97°C avec cœurs occupés et Bzy_MHz inférieur à l’attendu : ça sent la limite thermique.
Décision : Confirmez les températures via sensors/IPMI et planifiez une mitigation immédiate (drain/charge réduite).

Task 3: Read thermal sensors locally (lm-sensors)

cr0x@server:~$ sudo apt-get -y install lm-sensors >/dev/null
cr0x@server:~$ sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +98.0°C  (high = +84.0°C, crit = +100.0°C)
Core 0:        +96.0°C  (high = +84.0°C, crit = +100.0°C)
Core 1:        +97.0°C  (high = +84.0°C, crit = +100.0°C)

Signification : Vous frôlez le critique. Le fait que « high » soit dépassé signifie qu’un throttling soutenu est probable.
Décision : Si c’est un système récent ou entretenu récemment, priorisez une inspection physique (montage/pâte/autocollant).

Task 4: Check kernel for thermal events

cr0x@server:~$ sudo dmesg -T | egrep -i 'thermal|thrott|critical|overheat' | tail -n 8
[Mon Jan 22 10:41:12 2026] CPU0: Package temperature above threshold, cpu clock throttled
[Mon Jan 22 10:41:12 2026] CPU2: Package temperature above threshold, cpu clock throttled
[Mon Jan 22 10:41:15 2026] CPU0: Core temperature/speed normal

Signification : Le kernel vous dit qu’il a bridé. Ce n’est pas un « peut-être ».
Décision : Traitez cela comme la cause de l’incident, pas comme une ligne de log accessoire ; ajustez la capacité et corrigez le refroidissement.

Task 5: Confirm fan RPM and system temps via IPMI

cr0x@server:~$ sudo apt-get -y install ipmitool >/dev/null
cr0x@server:~$ sudo ipmitool sdr type Temperature
CPU Temp         | 98 degrees C      | critical
System Temp      | 36 degrees C      | ok
VRM Temp         | 92 degrees C      | non-critical

Signification : La température d’entrée/système est correcte ; CPU/VRM sont chauds. Cela oriente plutôt vers le contact/flux d’air interne que « la salle est chaude ».
Décision : Si les ventilateurs sont déjà à fond, suspectez un dissipateur bloqué, un mauvais montage, un autocollant ou une pompe morte (AIO).

Task 6: Check fan sensors via IPMI

cr0x@server:~$ sudo ipmitool sdr type Fan
FAN1             | 17600 RPM         | ok
FAN2             | 17400 RPM         | ok
FAN3             | 17100 RPM         | ok
FAN4             | 0 RPM             | critical

Signification : Un ventilateur est mort ou débranché. Sur certains châssis, un ventilateur manquant ruine le motif de pression.
Décision : Remplacez/remettez en place le ventilateur en premier. Si tous les ventilateurs sont OK et que les températures montent encore, passez à l’interface plaque froide.

Task 7: Read IPMI System Event Log for shutdown reasons

cr0x@server:~$ sudo ipmitool sel elist | tail -n 6
1a2 | 01/22/2026 | 10:42:01 | Temperature CPU Temp | Upper Critical going high
1a3 | 01/22/2026 | 10:42:05 | Processor #0 | Thermal Trip
1a4 | 01/22/2026 | 10:42:06 | System Boot Initiated | Initiated by power reset

Signification : Un Thermal trip a précédé la réinitialisation. Le BMC l’a vu.
Décision : Cessez de blâmer l’hyperviseur. Réparez le refroidissement. Conservez les logs pour le post-mortem.

Task 8: Verify power draw and power limit behavior (RAPL / turbostat)

cr0x@server:~$ sudo turbostat --Summary --interval 2 | head -n 4
turbostat version 2024.01
Summary: 2 sec
Avg_MHz   Busy%   Bzy_MHz  PkgTmp  PkgWatt
1450      88.40   1601     99      205.7

Signification : Puissance élevée à haute température, mais MHz médiocre : le refroidissement n’évacue pas la chaleur.
Décision : À court terme : appliquez une limite de puissance pour réduire la dérive thermique pendant que vous planifiez une réparation physique.

Task 9: Apply a temporary CPU power cap (safe mitigation)

cr0x@server:~$ sudo apt-get -y install linux-tools-common linux-tools-generic >/dev/null
cr0x@server:~$ sudo powercap-info -p intel-rapl:0
Zone intel-rapl:0
  enabled: 1
  constraint_0_power_limit_uw: 220000000
  constraint_1_power_limit_uw: 250000000
cr0x@server:~$ echo 160000000 | sudo tee /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
160000000

Signification : Vous avez abaissé la limite de puissance soutenue du package à 160W.
Décision : Utilisez cela pour maintenir le système assez longtemps pour évacuer les workloads. N’appelez pas ça une « correction » définitive.

Task 10: Stress test briefly to reproduce without frying it

cr0x@server:~$ sudo apt-get -y install stress-ng >/dev/null
cr0x@server:~$ sudo stress-ng --cpu 0 --cpu-method matrixprod --timeout 30s --metrics-brief
stress-ng: info:  [21432] dispatching hogs: 32 cpu
stress-ng: info:  [21432] successful run completed in 30.01s
stress-ng: info:  [21432] cpu: 960.00 bogo ops/s

Signification : Vous avez créé une charge thermique reproductible. Associez cela à sensors/turbostat pour voir la vitesse de montée en température.
Décision : Si les températures grimpent vers les hauts 90 en quelques secondes et que les ventilateurs sont à fond, arrêtez et inspectez montage/autocollant/pompe.

Task 11: Check NVMe thermal throttling (storage “mystery slowness”)

cr0x@server:~$ sudo apt-get -y install nvme-cli >/dev/null
cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep 'temperature|warning|critical'
temperature                             : 78 C
warning_temp_time                       : 134
critical_comp_time                      : 0

Signification : Le NVMe chauffe et a passé du temps au-dessus de son seuil d’avertissement. Il peut déjà être en throttling.
Décision : Ajoutez du flux d’air sur les NVMe, vérifiez les radiateurs, et arrêtez de supposer que le disque est « lent ». Il est peut-être « chaud ».

Task 12: Check for PCIe correctable errors (heat can destabilize links)

cr0x@server:~$ sudo dmesg -T | egrep -i 'aer|pcie|corrected|whea' | tail -n 6
[Mon Jan 22 10:39:44 2026] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
[Mon Jan 22 10:39:44 2026] pcieport 0000:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer

Signification : Pas définitif, mais des erreurs corrigées croissantes sous chaleur/charge peuvent indiquer une intégrité de signal marginale ou un stress thermique.
Décision : Si les erreurs corrèlent avec des températures élevées, corrigez le refroidissement avant de remplacer du matériel.

Task 13: Verify BMC fan mode/policy (mis-set can masquer as hardware failure)

cr0x@server:~$ sudo ipmitool raw 0x30 0x45 0x00
01

Signification : Spécifique au vendeur, mais renvoie souvent le mode actuel des ventilateurs (par ex. « standard » vs « full »).
Décision : Si la politique est trop silencieuse pour votre profil thermique, passez temporairement à un mode plus élevé ; puis revoyez le flux d’air correctement.

Task 14: Check container orchestration symptoms (node flaps look like software)

cr0x@server:~$ kubectl get nodes
NAME           STATUS     ROLES    AGE   VERSION
worker-07      NotReady   <none>   18d   v1.29.2
worker-08      Ready      <none>   18d   v1.29.2
cr0x@server:~$ kubectl describe node worker-07 | egrep -i 'Ready|KubeletNotReady|reboot|pressure' | tail -n 8
Ready                False   Mon, 22 Jan 2026 10:42:15 +0000   KubeletNotReady   runtime network not ready
Ready                True    Mon, 22 Jan 2026 10:30:02 +0000   KubeletReady      kubelet is posting ready status

Signification : Flapping de nœud. « Runtime network not ready » peut être un effet secondaire de réinitialisations brutales.
Décision : Vérifiez SEL du BMC et températures avant de courir après des fantômes CNI pendant trois heures.

Task 15: Confirm recent maintenance (sticker incidents correlate with “we touched it”)

cr0x@server:~$ last -x | head -n 8
reboot   system boot  6.8.0-40-generic Mon Jan 22 10:42   still running
shutdown system down  6.8.0-40-generic Mon Jan 22 10:41 - 10:42  (00:00)
reboot   system boot  6.8.0-40-generic Mon Jan 22 10:12 - 10:41  (00:29)

Signification : Plusieurs redémarrages dans une courte fenêtre : soit tests, instabilité, soit boucles d’arrêt thermique.
Décision : Recoupez avec les tickets de changement. Si un refroidisseur/CPU a été reseated récemment, priorisez l’inspection physique.

Task 16: If you must open the box, document and verify contact pattern

cr0x@server:~$ sudo mkdir -p /var/tmp/thermal-incident && sudo date | sudo tee /var/tmp/thermal-incident/notes.txt
Mon Jan 22 10:55:03 UTC 2026

Signification : Vous créez un dossier d’artefacts d’incident avant de manipuler les composants.
Décision : Prenez des photos de la plaque froide, de la présence d’autocollant et de la répartition de la pâte. C’est de l’or pour les post-mortems et la formation.

Blague n°2 (court, pertinent) : Si votre CPU atteint 100°C avec les ventilateurs à fond, ce n’est pas le « mode turbo » — c’est « s’il vous plaît, enlevez le plastique. »

Trois mini-récits d’entreprise depuis les tranchées de la surchauffe

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

Une entreprise de taille moyenne a déployé un nouveau lot de nœuds de calcul pour CI et environnements éphémères. Le matériel avait été pré-racké par un fournisseur, imagé en interne, puis rejoint au cluster. Pendant deux jours, tout semblait correct — parce que les charges étaient ponctuelles et courtes.

Le troisième jour, ils ont activé une nouvelle suite de tests qui lançait des compilations CPU intensives et soutenues. Soudain, les jobs ont commencé à expirer. Les ingénieurs y ont vu de la « contention de file » et ont augmenté la taille du pool de runners. Ça a empiré : davantage de nœuds ont atteint une charge soutenue, plus d’échecs se sont accumulés, et l’ordonnanceur avait l’air hanté.

La mauvaise hypothèse était subtile : « Si ça démarre et passe un test de fumée de 10 minutes, les thermiques sont corrects. » Ce n’était pas le cas. Le test de fumée n’atteignait jamais l’état stable. Sous charge soutenue, les CPU atteignaient les seuils thermiques, clampaient la fréquence, puis déclenchaient des arrêts. Certains nœuds récupéraient ; d’autres entraient en boucles de redémarrage qui ressemblaient à des problèmes de provisioning.

L’indice final est venu d’une seule personne qui a cessé de lire les logs logiciels et a extrait les données IPMI. Les événements critiques de température collaient avec les expirations de jobs. Un technicien a ouvert un châssis. La plaque froide avait encore le film protecteur.

Une fois qu’ils en ont trouvé un, ils en ont trouvé plusieurs. Une erreur de ligne d’assemblage par lot, pas une erreur isolée. La partie « drôle » a duré environ dix secondes ; le reste a été du recalcul de capacité, du retraitement des nœuds et la rédaction d’un nouveau test d’acceptation qui exécutait une charge soutenue réelle tout en enregistrant les températures.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a cherché des économies d’énergie. La facture du datacenter pesait, et la direction voulait des « gains d’efficacité ». Quelqu’un a proposé de réduire la vitesse des ventilateurs en passant la politique BMC d’un profil haute performance à une politique plus silencieuse et à plus bas RPM. Le changement a été déployé via l’automatisation.

Au début : succès. Moins de bruit en labo. Moins de consommation au repos. Puis le monde réel est arrivé. L’ambiance estivale a monté, les racks sont devenus plus denses, et quelques châssis avaient un flux d’air légèrement imparfait à cause de faisceaux de câbles et d’espaces de panneaux manquants. Sous charge de pointe, certains nœuds ont commencé à montrer des pics de latence intermittents. Rien de dramatique. Juste assez pour coûter cher.

L’optimisation s’est retournée contre eux parce qu’elle a réduit la marge. Avec moins de réserve de ventilateur, toute résistance thermique supplémentaire — poussière, pâte vieillissante, pression de dissipateur légèrement décalée, ou oui, un autocollant oublié après un remplacement de CPU — a poussé le système au-delà du seuil. Le même matériel qui supportait les erreurs à « ventilateurs max » ne le supportait plus en « eco fan ».

L’équipe a retenu deux leçons. Premièrement : la politique de ventilateurs fait partie du budget de fiabilité, pas seulement de l’acoustique. Deuxièmement : déployer des changements de mode ventilateur sans caractérisation thermique par châssis revient à jouer avec un dé pipé.

Ils ont récupéré en restaurant une courbe de ventilateurs plus agressive pour les racks de production, puis en appliquant sélectivement des politiques plus silencieuses uniquement là où les températures d’entrée et la densité du châssis le permettaient, avec des alarmes thermiques liées à l’automatisation pour inverser la politique quand les seuils sont atteints.

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

Une équipe de services financiers avait l’habitude, qui semblait fastidieuse : chaque intervention matérielle exigeait une checklist de « vérification physique » à deux personnes. Pas seulement « quelqu’un a signé », mais deux paires d’yeux confirmaient des éléments comme : autocollant retiré, pâte appliquée, séquence de serrage du refroidisseur respectée, connecteurs ventilateur branchés et déflecteurs d’air installés.

Lors d’une fenêtre de maintenance précipitée, ils ont dû remplacer un CPU dans un serveur qui hébergeait aussi des services de stockage sensibles à la latence. L’environnement était bruyant, chaud et plein de distractions. L’endroit exact où les autocollants prospèrent.

Le premier technicien a monté le refroidisseur, a commencé à refermer le châssis, puis la deuxième personne a posé la question de la checklist : « Film de la plaque froide enlevé ? » Ils ont fait une pause. Ont rouvert. Le film était encore là. Dix secondes pour corriger et ils ont évité ce qui aurait été un incident embarrassant avec des symptômes confus.

C’est le genre de pratique qui n’obtient pas d’applaudissements. Elle rapporte de l’uptime. Elle est aussi évolutive : quand il y a du turnover et que de nouvelles personnes arrivent, la checklist est la mémoire institutionnelle écrite en clair.

Erreurs courantes : symptôme → cause racine → correction

Les erreurs de surchauffe sont prévisibles. C’est une bonne nouvelle : vous pouvez construire des garde-fous. Voici des correspondances spécifiques qui changent les décisions, pas seulement l’ambiance.

1) Ventilateurs à 100 %, le CPU atteint encore 95–100°C rapidement → mauvais contact plaque froide → remonter, enlever le film, repaster

Symptôme : Montée rapide de la température ; throttling dans dmesg ; ventilateurs hurlants.
Cause racine : Film protecteur laissé, pression de montage inégale, ou pâte appliquée incorrectement (trop, pas assez, ou contaminée).
Correction : Couper l’alimentation, retirer le refroidisseur, nettoyer avec alcool isopropylique, enlever le film, appliquer la pâte correctement, serrer en croix selon le couple spécifié.

2) Températures CPU correctes mais le système redémarre sous charge → VRM ou chipset en surchauffe → restaurer le flux d’air et vérifier les pads

Symptôme : Température package CPU apparemment sûre, mais SEL montre des avertissements VRM ou des événements « power unit ».
Cause racine : Déflecteur d’air manquant, ventilateur mort, ou pad thermique VRM mal aligné après intervention.
Correction : Remplacer le ventilateur, restaurer les baffles/ducts, vérifier dissipateurs et pads, assurer la pression correcte du châssis.

3) Pics de latence stockage, CPU semble normal → throttling NVMe → ajouter radiateurs/flux d’air, déplacer les disques

Symptôme : Pics IO aléatoires ; NVMe à 70–85°C ; warning_temp_time augmente.
Cause racine : Disques sans flux d’air, radiateurs manquants, ou placés derrière des GPU chauds.
Correction : Installer des dissipateurs NVMe appropriés, améliorer le chemin d’air, utiliser panneaux obturateurs, envisager de déplacer les disques à fort IO vers des baies mieux refroidies.

4) Seules certaines charges déclenchent des problèmes → pic thermique lié au mix d’instructions → appliquer des limites de puissance ou planifier les jobs

Symptôme : Normal pour la plupart des tâches ; échoue pour certains calculs (math vectorielle, compression, chiffrement, rebuild intensif).
Cause racine : La charge génère une consommation soutenue plus élevée ; la marge de refroidissement est insuffisante.
Correction : Appliquer des caps de puissance, ajuster le comportement turbo, planifier les jobs lourds sur des fenêtres plus fraîches, ou améliorer le refroidissement/flux d’air.

5) Après une mise à jour firmware, les températures ont changé → politique de contrôle ventilateur modifiée → verrouiller la politique ou retuner les courbes

Symptôme : « C’était bien la semaine dernière », aucun changement matériel, mais les ventilateurs s’endorment plus bas et montent plus tard.
Cause racine : Mise à jour BMC/BIOS ayant altéré les courbes de ventilateurs ou l’interprétation des capteurs.
Correction : Vérifier les réglages de mode ventilateur, comparer au baseline, pinner sur une politique connue bonne, et mettre à jour vos contrôles d’automatisation.

6) Un nœud dans un rack surchauffe plus que ses voisins → obstruction locale du flux d’air → arranger câblage, obturateurs, portes

Symptôme : Même modèle de serveurs, même charge ; un seul chauffe.
Cause racine : Faisceau de câbles bloquant l’entrée, panneaux obturateurs manquants, obstruction partielle ou ventilateur défaillant.
Correction : Restaurer un flux d’air avant-arrière correct, remplacer le ventilateur, rerouter les câbles, installer les panneaux obturateurs.

Checklists / plan étape par étape

Quand vous suspectez une surchauffe en production (checklist ops)

Stabiliser le service : évacuer les workloads, réduire la concurrence, ou basculer si possible.
Confirmer les thermiques : sensors + BMC/IPMI + logs. Ne vous fiez pas à une seule source.
Mesurer le throttling : fréquence sous charge, pas au repos.
Déterminer l’étendue : nœud isolé vs flotte vs rack.
Mitiger en sécurité : cap de puissance temporaire, mode ventilateur plus élevé, ou limitation des workloads.
Planifier intervention physique : si matériel neuf/entretenu, supposez une cause physique et organisez un arrêt contrôlé.
Capturer pour postmortem : SEL, dmesg, snapshots capteurs, timing des workloads.

Quand vous construisez ou entretenez un serveur (checklist matériel)

Retirer le film de la plaque froide avant que la pâte n’entre en contact avec quoi que ce soit.
Nettoyer les surfaces (IHS et plaque froide) avec un solvant approprié et des lingettes non pelucheuses.
Appliquer la pâte correctement : méthode cohérente, petite quantité, pas de bulles, ne pas réutiliser de vieille pâte.
Monter avec pression uniforme : motif en croix, couple correct, pas de « un coin complètement serré d’abord ».
Confirmer les headers ventilateur/pompe connectés aux bons headers de la carte mère.
Vérifier les pièces de flux d’air : baffles, shrouds, panneaux obturateurs, conduits.
Exécuter un burn-in soutenu : au moins 20–30 minutes sous charge réelle tout en enregistrant les températures.
Enregistrer le baseline : température au repos, température en charge, RPM ventilateurs, ambiant, consommation CPU.

Arbre de décision « suspicion d’autocollant » (rapide et décisif)

Le refroidisseur/CPU a-t-il été touché récemment ? Si oui, suspectez d’abord l’interface.
Les températures montent-elles en quelques minutes sous charge modeste ? Si oui, interface/pompe/ventilateur probablement en cause.
Les ventilateurs/pompe fonctionnent-ils ? Si oui et que ça surchauffe encore, le contact physique est le suspect principal.
Pouvez-vous mitiger avec un cap de puissance ? Si oui, faites-le pour gagner du temps ; puis planifiez un arrêt et une inspection.

FAQ

1) L’erreur d’autocollant sur le refroidisseur est-elle vraiment courante en entreprise ?

Oui, surtout quand le matériel est assemblé ou entretenu sous pression temporelle, ou quand des fournisseurs pré-assemblent et que votre équipe suppose qu’un test d’acceptation le détectera. Les tests courts ne suffisent pas.

2) Le système ne démarrerait-il pas si l’autocollant était laissé ?

Habituellement il démarre. C’est pourquoi c’est dangereux. Au repos, le CPU peut survivre avec un mauvais transfert de chaleur. Sous charge soutenue, il ne le peut pas.

3) La pâte thermique peut-elle « brûler » ou compenser l’autocollant ?

Non. La pâte n’est pas magique. Elle réduit les minuscules poches d’air entre surfaces métalliques. Un film plastique crée une barrière continue à faible conductivité et piège souvent plus d’air.

4) Comment distinguer autocollant vs pompe morte sur un AIO ?

Les deux se ressemblent : montée de température rapide. Avec une pompe morte, vous pouvez voir la RPM de la pompe à 0 ou anormale, et le radiateur reste relativement froid tandis que le bloc CPU devient chaud. Les problèmes d’autocollant montrent souvent un mauvais motif de contact/pâte quand vous l’ouvrez.

5) Pourquoi la surchauffe ressemble-t-elle parfois à des problèmes de stockage ou réseau ?

Parce que le throttling augmente la latence partout : délais d’ordonnancement CPU, délais de gestion des interruptions, délais de soumission IO. Ajoutez le throttling NVMe et vous obtenez une parfaite diversion.

6) Quel est un « burn-in » sûr pour détecter ça sans risquer le matériel ?

Une charge soutenue contrôlée de 20–30 minutes (stress CPU plus IO réaliste s’il s’agit d’un nœud de stockage) tout en surveillant températures, RPM ventilateurs et flags de throttling. Stoppez si vous approchez des seuils critiques.

7) Les serveurs se protègent-ils de façon fiable contre la surchauffe ?

Ils essaient. Le throttling thermique et les trips sont conçus pour protéger le silicium, pas votre disponibilité. Un « arrêt protecteur » est toujours une panne, et des trips répétés peuvent stresser les composants.

8) Faut-il laisser les ventilateurs à fond tout le temps pour éviter ça ?

Non. Les ventilateurs à fond masquent les problèmes et augmentent l’usure et le bruit. Utilisez des courbes de ventilateurs appropriées pour votre environnement, et comptez sur un bon assemblage, un flux d’air propre et de la surveillance. Augmentez la politique ventilateur seulement comme mitigation ou là où c’est validé.

9) Que dois-je surveiller pour détecter tôt les problèmes thermiques ?

Température du package CPU, fréquence CPU sous charge, RPM ventilateurs, consommation électrique et événements SEL du BMC. Pour les nœuds de stockage, ajoutez la température NVMe et les indicateurs de throttling.

10) Quel est le meilleur « correctif processuel » humain ?

Une étape de vérification physique à deux personnes pour tout travail sur refroidisseur/CPU, plus un court test de charge soutenue avec enregistrement des températures avant que la machine ne retourne en production.

Étapes pratiques suivantes

La surchauffe est une de ces classes de défaillance où la différence entre une anecdote drôle et un vrai incident est de la traiter comme une préoccupation opérationnelle de premier plan. L’autocollant est drôle une seule fois, et seulement si ça arrive sur une machine non critique.

Une idée de fiabilité paraphrasée de W. Edwards Deming : « Vous ne pouvez pas gérer ce que vous ne mesurez pas. » En thermique, cela signifie températures, fréquences, RPM ventilateurs et puissance — liés aux changements et événements de maintenance.

Ajoutez un test d’acceptation thermique soutenu pour les nœuds neufs ou entretenus (avec relevés de températures et vérifications de throttling).
Instrumentez BMC/IPMI dans votre monitoring pour que les alarmes thermiques ne restent pas derrière une page de login.
Codifiez une checklist physique (incluant « retirer le film de la plaque froide ») et exigez une vérification à deux personnes.
Définissez un runbook de mitigation : évacuer les workloads, définir des caps de puissance temporaires, augmenter la politique ventilateurs, puis planifier la réparation physique.
Auditez les bases du flux d’air : panneaux obturateurs, discipline des câbles, filtres à poussière et santé des ventilateurs.

Si vous ne faites qu’une chose : la prochaine fois qu’un nœud surchauffe après une maintenance, cessez de négocier avec les logs et ouvrez le châssis. L’autocollant se moque de vos tableaux de bord.