De la pâte thermique partout : quand l’enthousiasme défie la physique

Cet article vous a aidé ?

Vous ouvrez le châssis parce que « c’est juste un repaste rapide », et dix minutes plus tard vous êtes en train d’essuyer une substance grise sur une carte mère comme si vous faisiez le detailing d’une voiture.
Le serveur redémarre… puis il se met à brider. Ou pire : il reboot sous charge, juste au moment où votre reconstruction de stockage est à 72 %.

La pâte thermique est ennuyeuse jusqu’à ce qu’elle ne le soit plus. Dans les systèmes de production, c’est un primitif de fiabilité : une couche minuscule et salissante qui décide si votre CPU fonctionne selon les spécifications ou passe son temps à négocier avec la physique. Voici ce qui tourne réellement mal quand les gens s’emportent, et comment le diagnostiquer avec la même rigueur que vous appliquez aux pics de latence et aux erreurs disque.

La physique à laquelle on ne peut pas déroger

La pâte thermique (TIM : thermal interface material) n’est pas « un meilleur conducteur que le métal ». C’est l’inverse. Elle existe parce que les surfaces métalliques réelles ne sont pas plates.
Si vous mettez un spreader de CPU contre un dissipateur, vous n’obtenez pas un contact parfait. Vous obtenez des pics microscopiques en contact et beaucoup d’air piégé dans les vallées.
L’air est un conducteur désastreux. La pâte est « moins désastreuse que l’air », donc elle comble les vides.

L’objectif n’est pas une couche épaisse. L’objectif est une couche mince et continue qui remplace l’air tout en maintenant un contact métal-métal maximal. Si vous mettez trop
de pâte, vous augmentez l’épaisseur de la couche, et comme la pâte conduit moins bien que le cuivre ou l’aluminium, votre résistance thermique augmente. C’est la première
et la plus fréquente des erreurs « l’enthousiasme bat la physique ».

La deuxième erreur est mécanique : la pâte est glissante. L’excès de pâte peut modifier l’assise du dissipateur. Un refroidisseur légèrement incliné ou pas serré uniformément peut créer
un motif de contact qui semble correct à l’œil nu mais génère un point chaud sur un groupe de cœurs sous charge AVX. Les CPU modernes se protégeront en bridant,
mais « protégé » signifie toujours « plus lent », et dans les systèmes distribués, le plus lent est contagieux.

La troisième erreur est la contamination. La plupart des pâtes sont nominalement non conductrices électriquement, mais « non conductrice » n’est pas « sûr à étaler sur de minuscules composants ».
Certaines pâtes sont légèrement capacitives ; d’autres contiennent des métaux ; certaines deviennent conductrices lorsqu’elles sont contaminées ou vieillissent. Et même si la pâte elle-même est électriquement inoffensive,
elle attire poussière et fibres, et rend l’inspection et la retouche pénibles.

Voici la vérité opérationnelle : si le comportement thermique d’un serveur change après un repaste, supposez que vous l’avez empiré jusqu’à preuve du contraire. Cela ne veut pas dire que vous êtes incompétent.
Cela signifie que le système fonctionnait déjà, et vous avez modifié plusieurs variables à la fois : épaisseur de l’interface, pression de montage, courbes de ventilateurs (souvent), et circulation d’air
(vous aviez le capot ouvert). Commencez par la mesure, pas par l’intuition.

Une citation qui devrait figurer sur le mur de chaque équipe d’exploitation, de Richard Feynman :
Pour une technologie qui réussit, la réalité doit primer sur la communication, car la nature ne se laisse pas tromper.
C’est court, rugueux, et vrai.

Blague n°1 : La pâte thermique, c’est comme le parfum — si on la voit de l’autre côté de la pièce, vous en avez mis trop.

À quoi ressemble une application correcte (et pourquoi le « pois » n’est pas universel)

Les conseils sur Internet adorent le « point de la taille d’un pois ». Ce n’est pas faux dans l’esprit, mais c’est incomplet. Les CPU ont des configurations de die différentes sous le spreader.
Les dissipateurs appliquent des distributions de pression différentes. Certains sockets sont rectangulaires et longs (HEDT et plateformes serveur), ce qui fait que la méthode « un point »
peut laisser les coins sous-remplis. Une fine ligne ou un X peut être meilleur pour de grandes empreintes d’IHS.

L’approche sensée est ennuyeuse : utilisez une méthode connue et fiable par plateforme, appliquez un couple constant, et validez avec un contrôle du motif de contact lorsque vous changez de refroidisseur ou de type de pâte.
Si vous travaillez sur une flotte, standardisez. La cohérence bat l’artisanat de la pâte.

Pourquoi l’idée « plus de pâte = meilleur refroidissement » survit

Ça semble intuitif : plus de matériau entre deux choses signifie plus de transfert. C’est vrai quand le matériau est meilleur que l’espace. L’espace, c’est l’air (terrible), donc la première
petite quantité de pâte aide beaucoup. Après cela, vous ne remplacez plus l’air. Vous remplacez le contact métallique par une épaisseur de pâte. Et maintenant vous payez pour ça.

En termes serveurs : la pâte est comme un cache. Un peu, c’est bien. Toute la mémoire qui prétend être cache, ce n’est plus que… de la mémoire.

Faits et contexte historique (la version sans mythes)

  • Fait 1 : L’électronique haute puissance utilisait des graisses et huiles comme matériaux d’interface des décennies avant que le repastage en PC grand public ne devienne un hobby.
  • Fait 2 : Le « compound thermique » est devenu courant dans les PC lorsque la densité de puissance des CPU a augmenté et que le décalage entre surfaces brillantes et platitude réelle est devenu important.
  • Fait 3 : Même des surfaces métalliques polies ont des aspérités microscopiques ; la douceur optique n’est pas la douceur thermique.
  • Fait 4 : La conductivité typique des pâtes thermiques est bien inférieure à celle du cuivre ; leur valeur réside dans le remplacement de l’air, pas dans la supériorité au métal.
  • Fait 5 : Les matériaux d’interface à changement de phase (pads qui s’assouplissent/fondent légèrement en température) existent pour simplifier la constance d’assemblage en production.
  • Fait 6 : Le « pump-out » est réel : le cyclage thermique et les contraintes mécaniques peuvent faire migrer la pâte hors de la zone de contact la plus chaude avec le temps.
  • Fait 7 : Certaines pâtes sont électriquement conductrices (notamment les composés métal-liquide), et elles exigent isolation, masquage et un niveau d’exécution plus élevé.
  • Fait 8 : Beaucoup de dissipateurs serveurs sont conçus pour une pression de montage et un flux d’air spécifiques ; passer à une approche « aftermarket » peut casser le modèle thermique.
  • Fait 9 : Le throttling thermique est devenu plus agressif et granulaire dans les CPU modernes ; vous pouvez perdre des performances sans plantage, ce qui rend l’échec facile à manquer.

Ce que « pâte thermique partout » casse vraiment

Mode d’échec 1 : Résistance thermique accrue due à un TIM épais

Trop de pâte crée une couche plus épaisse. La résistance thermique augmente. Les températures montent plus vite sous charge et se stabilisent à un équilibre plus élevé. Vous observez un
rampage des ventilateurs plus précoce, un bridage anticipé et une réduction du temps en turbo. En production, cela se traduit par des temps d’exécution de jobs plus longs, plus de latence en queue,
et parfois des resets watchdog sur des systèmes aux limites thermiques serrées.

Mode d’échec 2 : Mauvais contact dû au montage inégal

L’excès de pâte peut hydroplaner le dissipateur lors de l’installation, surtout si vous serrez trop fortement un coin trop tôt. Le dissipateur peut emprisonner un coin de pâte et ne jamais s’assoir complètement.
Vous verrez souvent un ou deux cœurs ou un CCD plus chauds que les autres, pas une augmentation uniforme. Ce motif compte : il crie « problème de contact » plus que « problème d’aéraulique ».

Mode d’échec 3 : Pâte aux mauvais endroits

La pâte étalée sur les bords du socket, les composants CMS ou entre les pins est un cadeau qui continue à faire des dégâts. Même les composés « non conducteurs » peuvent créer des chemins de fuite lorsqu’ils sont mélangés à de la poussière.
Cela complique aussi les inspections ultérieures : on ne distingue plus facilement si un composant est fissuré, carbonisé, ou simplement recouvert d’un manteau gris tendance.

Mode d’échec 4 : Mauvaise pâte pour le profil d’exploitation

Les postes et les serveurs ne vivent pas la même vie. Un serveur peut tourner en charge soutenue, avec des températures d’entrée élevées et un cyclage thermique constant. Certaines pâtes grand public se dessèchent,
se séparent ou pump-outent plus vite sous ce régime. À l’inverse, certains composés haute performance sont capricieux et exigent un montage parfait et une préparation de surface stricte.

Mode d’échec 5 : Poursuivre la pâte alors que le vrai problème est l’air

Le diagnostic classique erroné : « Le CPU est chaud, donc la pâte est mauvaise. » Dans une baie, la température d’entrée, les panneaux d’obturation, les faisceaux de câbles, la santé des ventilateurs et les courbes BMC sont
souvent les vrais coupables. La pâte est la chose la plus facile à manipuler, donc elle est blâmée. Pendant ce temps, le serveur respire l’air chaud du voisin parce que quelqu’un a retiré un panneau il y a des mois et personne n’a voulu ouvrir un ticket.

Blague n°2 : Si votre application de pâte ressemble à de l’art moderne, le CPU répondra par de l’art performance — essentiellement du throttling interprétatif.

Cahier de jeu : diagnostic rapide

Quand une machine chauffe après un repaste — ou commence à brider pendant des charges normales — ne recommencez pas par un nouveau repaste. Isolez le goulot d’étranglement en trois passages :
(1) confirmer capteurs et symptômes, (2) corréler avec comportement puissance et fréquence, (3) valider flux d’air et contact mécanique. Vous essayez de répondre rapidement à une question :
le facteur limitant est-il la génération de chaleur, le transfert de chaleur, ou l’évacuation de chaleur ?

Premier : confirmer que le symptôme est réel et spécifique

  • Vérifier la température du package CPU, les deltas par cœur/CCD, et si le BMC est en accord avec l’OS.
  • Rechercher les drapeaux de throttling thermique et les chutes de fréquence sous charge.
  • Comparer avec un hôte frère connu bon si vous en avez un.

Deuxième : corréler les thermiques avec la charge et la puissance

  • Est-ce déclenché par la charge (uniquement lors d’AVX ou compression), déclenché par le temps (après 20 minutes), ou par l’ambiance (seulement aux pics d’allée chaude) ?
  • Les ventilateurs montent-ils en régime ? Si les ventilateurs sont bas alors que le CPU est chaud, suspectez le contrôle ventilateur / politiques BMC.
  • Êtes-vous limité en puissance (clamp package) plutôt qu’en thermique ?

Troisième : valider le flux d’air et le contact mécanique

  • Flux d’air : températures d’entrée, RPM des ventilateurs du châssis, filtres bouchés, panneaux manquants, câbles obstruant le flux.
  • Mécanique : schéma de serrage du dissipateur, entretoises de montage, alignement de la plaque arrière, plaque froide déformée, entretoise correcte pour le socket.
  • TIM : bonne quantité, pas de vides, pas de contamination, type de pâte adapté à la plage de température.

Si vous suivez cet ordre, vous évitez l’erreur la plus coûteuse : refaire des interventions physiques à répétition sans changement mesurable, ce qui transforme un problème technique en incident de fiabilité avec du temps d’arrêt en sus.

Tâches pratiques : commandes, sorties et décisions

Voici des commandes réelles que vous pouvez lancer sur des serveurs Linux typiques pour déterminer si votre problème vient du throttling, des capteurs, du flux d’air ou du contact. Chaque tâche inclut
ce que signifie la sortie et ce que vous devez décider ensuite. Utilisez-les comme vous utiliseriez iostat pour le stockage : comme des preuves, pas pour la déco.

Task 1: Check basic CPU temperatures and per-core spread

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +86.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +85.0°C  (high = +90.0°C, crit = +100.0°C)
Core 1:        +86.0°C  (high = +90.0°C, crit = +100.0°C)
Core 2:        +68.0°C  (high = +90.0°C, crit = +100.0°C)
Core 3:        +69.0°C  (high = +90.0°C, crit = +100.0°C)

Signification : Deux cœurs sont ~17–18°C plus chauds que les autres dans des conditions similaires. Ce n’est pas « flux d’air du boîtier » ; c’est souvent un contact inégal ou un point chaud localisé.

Décision : Passez aux vérifications de throttling puis à une inspection mécanique si le motif persiste sous une charge contrôlée.

Task 2: Watch temperatures and fan behavior live

cr0x@server:~$ watch -n 1 'sensors | egrep "Package id 0|Core 0|Core 2|fan"'
Every 1.0s: sensors | egrep Package id 0|Core 0|Core 2|fan

Package id 0:  +92.0°C
Core 0:        +91.0°C
Core 2:        +74.0°C
fan1:          8200 RPM
fan2:          8100 RPM

Signification : Les ventilateurs tournent à fond ; le système fait l’effort. Les températures restent élevées, avec un grand delta. L’évacuation fonctionne ; le transfert de chaleur (TIM/contact) est suspect.

Décision : Validez les drapeaux de throttling ; préparez une réinstallation avec le bon couple et la bonne quantité de pâte.

Task 3: Confirm CPU frequency and throttling during load

cr0x@server:~$ lscpu | egrep "Model name|CPU MHz|Thread|Socket"
Model name:                           Intel(R) Xeon(R) CPU
Thread(s) per core:                   2
Socket(s):                            2
CPU MHz:                              1199.992

Signification : Si vous êtes sous charge et que vous voyez ~1.2 GHz sur un CPU qui devrait être bien plus élevé, vous êtes probablement en train de brider ou limité en puissance.

Décision : Vérifiez les logs du noyau pour des événements de throttling thermique et comparez aux limites de puissance.

Task 4: Look for thermal throttling messages in kernel logs

cr0x@server:~$ sudo dmesg -T | egrep -i "thermal|throttl|PROCHOT|temperature" | tail -n 10
[Mon Jan 22 10:14:05 2026] CPU0: Package temperature above threshold, cpu clock throttled (total events = 37)
[Mon Jan 22 10:14:05 2026] CPU1: Package temperature above threshold, cpu clock throttled (total events = 37)

Signification : C’est du throttling thermique explicite. Pas un « peut-être ». Pas un « l’utilisateur dit que c’est lent ».

Décision : Déterminez si cela vient du flux d’air/ambiance ou d’une mauvaise interface/montage en vérifiant ensuite l’entrée d’air et le contrôle des ventilateurs.

Task 5: Read BMC/IPMI sensor data (temps, fans, inlet)

cr0x@server:~$ sudo ipmitool sdr elist | egrep -i "inlet|ambient|cpu|fan" | head -n 12
Inlet Temp       | 24 degrees C      | ok
CPU1 Temp        | 91 degrees C      | ok
CPU2 Temp        | 89 degrees C      | ok
FAN1             | 8100 RPM          | ok
FAN2             | 8200 RPM          | ok
FAN3             | 7900 RPM          | ok

Signification : L’entrée est raisonnable ; les températures CPU sont élevées ; les ventilateurs tournent vite et sont sains. Cela oriente loin des problèmes d’allée chaude et vers le contact/TIM du dissipateur.

Décision : Planifiez une fenêtre de maintenance pour reseater ; ne perdez pas de temps à reconfigurer les courbes de ventilateurs.

Task 6: Verify CPU governor and frequency policy (avoid self-inflicted throttling)

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

Signification : Vous ne tournez pas en « powersave ». Bien. Si c’était « powersave », vous pourriez interpréter à tort des fréquences basses comme du throttling thermique.

Décision : Poursuivre les vérifications de limites de puissance/thermiques plutôt que d’ajuster la politique CPU.

Task 7: Check for power capping (can masquerade as thermal issues)

cr0x@server:~$ sudo ipmitool dcmi power reading
    Instantaneous power reading:                   412 Watts
    Minimum during sampling period:                380 Watts
    Maximum during sampling period:                430 Watts
    Average power reading over sample period:      405 Watts
    IPMI timestamp:                           Mon Jan 22 10:20:10 2026
    Sampling period:                          00000010 Seconds.

Signification : Ceci montre la consommation effective ; cela ne prouve pas que vous êtes plafonné, mais cela donne du contexte. Si votre plateforme impose un cap strict, les fréquences peuvent chuter même à des températures sûres.

Décision : Si les températures sont élevées et les fréquences basses, c’est thermique. Si les températures sont modérées et les fréquences basses, suspectez un power capping ou des limites BIOS.

Task 8: Identify whether a specific process triggers the heat spike

cr0x@server:~$ top -b -n 1 | head -n 15
top - 10:22:31 up 18 days,  3:12,  1 user,  load average: 63.12, 58.77, 41.09
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.1 us,  0.3 sy,  0.0 ni, 97.4 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem : 257843.1 total,  98212.7 free,  40117.2 used, 119513.2 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
28412 app       20   0  12.3g  2.1g  112m R  780.0   0.8  12:31.44 compressor

Signification : Un seul workload (compression/crypto/charge AVX) peut pousser les thermiques bien plus loin que vos tests habituels.

Décision : Utilisez un test de charge reproductible (même binaire) lors de la validation d’un reseat ; sinon vous courrez après du bruit.

Task 9: Stress test in a controlled way to reproduce the issue

cr0x@server:~$ sudo apt-get install -y stress-ng
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  stress-ng
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

Signification : Vous avez maintenant un outil cohérent pour générer de la charge.

Décision : Lancez un court stress et surveillez les températures ; ne le faites pas en production sans fenêtre de maintenance et limites de sécurité.

cr0x@server:~$ sudo stress-ng --cpu 32 --timeout 60s --metrics-brief
stress-ng: info:  [31201] dispatching hogs: 32 cpu
stress-ng: metrc: [31201] cpu                60.00s  12345.67 bogo ops/s
stress-ng: info:  [31201] successful run completed in 60.02s

Signification : Une charge reproductible de 60 secondes permet des comparaisons avant/après. Associez-la à watch sensors.

Décision : Si le throttling arrive vite, c’est probablement contact/TIM. Si cela met longtemps, suspectez le flux d’air, des filtres bouchés ou l’ambiance.

Task 10: Check for corrected hardware errors that correlate with heat

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | egrep -i "mce|edac|hardware error" | tail -n 10
Jan 22 10:09:12 server kernel: mce: [Hardware Error]: Machine check events logged
Jan 22 10:09:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

Signification : La chaleur peut exacerber des composants marginaux. Un repaste qui augmente les températures peut transformer « erreurs correctables rares » en « incident ».

Décision : Traitez les problèmes thermiques comme des risques de fiabilité ; planifiez une remédiation avant que les erreurs ne deviennent irréversibles.

Task 11: Validate storage latency during thermal throttling (because it will show up)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	01/22/2026 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    3.22    0.85    0.00   83.62

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s wrqm/s  %util  r_await  w_await
nvme0n1         12.0   220.0   512.0  8192.0     0.0    0.0   68.5    2.10    9.80

Signification : Pendant le throttling, le CPU peut devenir le goulot d’étranglement et gonfler les temps de traitement des requêtes, ce qui peut ressembler à un « stockage qui a ralenti ».

Décision : Si la latence stockage augmente pendant que les fréquences CPU baissent et que les températures grimpent, corrigez d’abord la thermique avant d’ajuster l’I/O.

Task 12: Verify ZFS scrub/resilver isn’t turning thermals into a self-inflicted outage

cr0x@server:~$ zpool status
  pool: tank
 state: ONLINE
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Jan 22 09:41:03 2026
        1.20T scanned at 1.68G/s, 612G issued at 858M/s, 4.10T total
        612G resilvered, 14.58% done, 0 days 01:10:22 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

Signification : La resilver sollicite fortement le CPU et la mémoire (checksums, compression, parité). Si vos thermiques CPU sont marginaux, ce type de charge les trouvera.

Décision : Si vous bridez, envisagez de mettre en pause ou de planifier ces travaux de maintenance lourds jusqu’à correction du refroidissement — sinon vous prolongez la période risquée.

Task 13: Check BMC event log for thermal or fan events

cr0x@server:~$ sudo ipmitool sel list | tail -n 8
 217 | 01/22/2026 | 10:14:06 | Temperature #0x01 | Upper Critical going high | Asserted
 218 | 01/22/2026 | 10:14:10 | Temperature #0x01 | Upper Critical going high | Deasserted
 219 | 01/22/2026 | 10:14:12 | Processor #0x01   | IERR | Asserted

Signification : Le BMC a vu un franchissement de seuil thermique. Un événement processeur peut aussi indiquer une instabilité liée à la chaleur.

Décision : Escaladez. Le thermique n’est plus cosmétique ; il provoque désormais des fautes matérielles.

Task 14: Check whether the chassis thinks the lid is present (yes, this happens)

cr0x@server:~$ sudo ipmitool sdr elist | egrep -i "intrusion|chassis"
Chassis Intrusion | Not Available     | ok

Signification : Certaines plateformes ajustent le comportement des ventilateurs selon les capteurs d’intrusion/châssis. Si celui-ci est déclenché, le contrôle des ventilateurs peut se comporter bizarrement.

Décision : Si l’intrusion est affirmée ou « ouverte », corrigez l’état physique d’abord ; ne paramétrez pas le logiciel autour d’un capot manquant.

Trois mini-récits d’entreprise sur le terrain

1) L’incident causé par une mauvaise hypothèse

Une société SaaS de taille moyenne disposait d’une flotte de serveurs de base de données stables depuis des années. Puis un rafraîchissement matériel de routine a eu lieu : même famille CPU, stepping un peu plus récent,
nouvelle révision de la fixation du dissipateur fournie par le vendeur. Rien d’effrayant. Un technicien a repasté quelques hôtes pendant le rack-and-stack parce que certains dissipateurs semblaient « un peu secs ». Cela semblait responsable.

La mauvaise hypothèse était simple : plus de pâte améliore les thermiques, et « ça va s’étaler ». Le technicien a utilisé une quantité généreuse et a fait une installation rapide — serré un coin,
puis l’opposé, mais pas en étapes incrémentales. Les machines ont démarré. Les températures semblaient correctes au repos. Tout le monde est rentré chez soi.

Le lendemain, le cluster de bases de données a commencé à montrer des pics de latence imprévisibles. Pas massifs. Juste assez pour déclencher des retries, qui ont créé plus de charge, qui ont créé
plus de chaleur. Lors du job analytics nocturne, deux nœuds ont commencé à brider, ont pris du retard dans la réplication, et ont été mis hors circuit par le gestionnaire de cluster comme « lents et non sains ».
Le basculement a fonctionné, mais c’était chaotique : un épisode de disponibilité, une pluie de pages, et une longue réunion RCA.

Le post-mortem portait moins sur la pâte que sur la discipline. Ils ont comparé la télémétrie thermique entre les nœuds « repastés » et « intacts » et ont trouvé une signature claire :
températures de package plus élevées sous charge et plus grand delta par cœur. La correction n’a rien d’héroïque. Ils ont ramené les machines en fenêtre de maintenance, nettoyé correctement,
appliqué une quantité mesurée, serré en croix avec un couple constant, et validé avec un test de stress avant de les remettre en pool.

La vraie leçon : supposer qu’un changement physique est bénin parce que le système boote revient à supposer qu’un changement de stockage est sûr parce que le système de fichiers se monte. Boot n’est pas un benchmark. C’est un bonjour.

2) L’optimisation qui s’est retournée contre eux

Une autre organisation — grande, économe, et fière de son « efficacité » — voulait réduire le bruit de ventilateurs et la consommation d’énergie dans un labo devenu discrètement une zone de préproduction.
Quelqu’un a décidé « d’optimiser » les thermiques : réappliquer une pâte haute conductivité premium sur la flotte puis abaisser légèrement les courbes des ventilateurs via les réglages BMC.
L’argument : une meilleure pâte nous permet de faire tourner les ventilateurs moins vite.

La pâte était correcte. Le processus ne l’était pas. Ils ont utilisé une méthode d’étalement pour créer une couche parfaite à l’œil, mais ils ne contrôlaient pas l’épaisseur. Certains dissipateurs se sont retrouvés
avec une couche de pâte tout simplement trop épaisse. Les machines ont tourné plus frais au repos — parce que tout tourne plus frais au repos — et le changement de courbe a donné l’impression
d’un environnement plus calme et « stable ». Slide de victoire.

Puis ils ont exécuté des tests de charge en staging plus réalistes que leurs tests synthétiques précédents. Sous charges CPU soutenues, les températures ont monté lentement, les ventilateurs sont montés tard
(à cause de la nouvelle courbe), et les CPU ont commencé à rétrograder. Les résultats de performance semblaient pires. L’équipe a alors supposé que la nouvelle pâte nécessitait un « rodage », parce que c’est le mythe auquel on se raccroche quand on a déjà choisi un récit.

Au final, l’optimisation a échoué deux fois : le changement de courbe a réduit la marge thermique, et l’épaisseur de TIM incohérente a augmenté la résistance thermique. Ils ont rétabli la politique des ventilateurs,
standardisé la méthode d’application, et ce n’est qu’après cela que la « pâte premium » a produit une amélioration mesurable. Le coût a été surtout du temps et de la crédibilité, qui en milieu corporate ne se renouvelle pas.

Règle opérationnelle : ne jamais regrouper changements physiques et changements de politique à moins d’être prêt à les bisecter. Si vous ne pouvez pas bisecter, vous n’apprendrez pas.

3) La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe de stockage gérant des nœuds denses compute+NVMe avait une habitude presque comique : à chaque retrait de dissipateur, ils le notaient comme un échange de disque.
Ticket, raison, type de pâte, méthode, schéma de couple, et un snapshot « avant/après » d’un test de stress de 60 secondes. Personne n’aimait le faire. Tout le monde adorait l’avoir plus tard.

Pendant un gel de changement de fin de trimestre, un nœud a commencé à brider par intermittence. Il ne tombait pas en erreur complète. Il était juste lent. Le service qu’il hébergeait avait des SLOs stricts de latence en queue,
et ce nœud tirait toute la pool vers le bas. À cause du gel, l’équipe avait besoin de preuves avant de demander une exception pour travaux physiques.

Ils ont extrait les données historiques de l’hôte et ont vu que les températures de package sous le test standard avaient augmenté d’environ 10°C depuis la dernière maintenance. Ils ont aussi vu qu’un retrait de dissipateur
avait été enregistré deux mois plus tôt pour un RMA de carte mère. Cela leur a donné une hypothèse plausible : un problème d’assise subtil ou un pump-out.

Ils ont obtenu l’exception, réinstallé le dissipateur selon leur procédure standard, et le test après correspondait à la ligne de base. Pas de drame, pas de suppositions, pas de « essayez une autre marque de pâte ».
L’hôte est revenu en pool, et la fin de trimestre s’est déroulée sans incident de performance.

Voilà à quoi ressemble l’ennuyeux quand il fonctionne : un petit rituel de mesure et de documentation qui transforme un mystère thermique en tâche de maintenance prévisible.

Erreurs courantes : symptômes → cause → correction

1) Températures CPU élevées immédiatement après un repaste

Symptômes : Les températures sont pires qu’avant ; les ventilateurs montent vite ; bridage sous charge modeste.

Cause racine : Trop de pâte (couche épaisse), poches d’air piégées, dissipateur mal assis.

Correction : Retirer le dissipateur, nettoyer complètement les deux surfaces, appliquer une petite quantité mesurée, reseater en serrant en croix par paliers. Valider par un test de charge reproductible.

2) Un cœur/CCD beaucoup plus chaud que les autres

Symptômes : Grand delta par cœur sous charge ; la température du package semble « à peu près » mais un hotspot atteint les seuils.

Cause racine : Pression de montage inégale, inclinaison, entretoise incorrecte, base du dissipateur voilée, coin de pâte.

Correction : Vérifier la compatibilité du matériel de montage ; reseater ; assurer un couple uniforme. Envisager d’inspecter le motif de contact (empreinte fine de pâte) pour confirmer la couverture.

3) Températures correctes au repos, mauvaises après 20–60 minutes

Symptômes : Montée graduelle puis bridage ; souvent corrélé à des charges soutenues (scrubs, rebuilds, jobs batch).

Cause racine : Restriction du flux d’air (filtres, faisceaux de câbles), courbe de ventilateur trop conservative, pics d’ambiance/entrée, pump-out de la pâte avec le temps.

Correction : Vérifier la température d’entrée et le RPM des ventilateurs via le BMC ; inspecter le chemin d’air ; restaurer la politique de ventilateurs du vendeur ; si l’historique le suggère, reseater avec une pâte résistante au pump-out.

4) Systèmes qui rebootent sous charge, thermiques « semblent normaux »

Symptômes : Reboots aléatoires ; parfois pas de log thermique clair ; événements MCE/EDAC occasionnels.

Cause racine : Point chaud localisé non capté par le capteur que vous surveillez, VRM qui surchauffe, mauvais alignement du dissipateur, ou couvercle/ducting manquant provoquant la surchauffe d’un composant.

Correction : Utiliser les capteurs BMC au-delà du CPU (VRM, carte mère, entrée). Confirmer que le ducting et les conduits sont installés. Reverifier l’assise du dissipateur. Ne pas ignorer les erreurs correctées.

5) Ventilateurs bloqués bas alors que la température monte

Symptômes : CPU atteint 90°C, les ventilateurs restent à bas RPM ; pas de panne de ventilateur évidente.

Cause racine : Mauvaise configuration de la politique BMC, capteur d’intrusion châssis activé, ou bug firmware.

Correction : Comparer les températures de l’OS à celles du BMC ; vérifier le SEL pour des événements de politique ; restaurer le profil thermique par défaut ; mettre à jour le firmware BMC pendant une fenêtre contrôlée.

6) Pâte sur le socket/composants après intervention

Symptômes : Contamination visuelle ; problèmes de boot intermittents ; instabilité inexpliquée après maintenance.

Cause racine : Sur-application et étalement pendant le retrait/installation du dissipateur ; mauvaise méthode de nettoyage.

Correction : Couper l’alimentation, démonter avec soin, nettoyer avec un solvant approprié et des outils non pelucheux, inspecter sous une forte lumière. Si une pâte conductrice a été utilisée, traitez cela comme un incident et envisagez le remplacement de la carte.

7) « On a repasté et c’est toujours chaud »

Symptômes : Aucune amélioration après plusieurs repastes ; tout le monde est fatigué ; le système reste marginal.

Cause racine : Le problème n’est pas la pâte : mauvais modèle de dissipateur, chicane manquante, matériel de montage incorrect, ventilateur dégradé, ailettes du dissipateur bouchées, ou température d’entrée trop élevée.

Correction : Arrêtez de repaster. Validez les numéros de pièce, les chicanes et le flux d’air. Vérifiez les ventilateurs et la propreté des ailettes. Comparez à un hôte connu bon dans la même baie.

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

Étape par étape : la procédure « faire une fois et bien » de repaste (niveau serveur)

  1. Planifiez la validation. Choisissez un test de charge reproductible (par ex. stress-ng --cpu N --timeout 60s) et enregistrez les températures et fréquences de base avant toute intervention matérielle.
  2. Programmez une fenêtre. Prévoyez du temps pour un nettoyage soigné et un test post-travail. La précipitation est la manière dont la pâte devient un mode de vie.
  3. Coupez l’alimentation et déchargez. Retirez les cordons d’alimentation, attendez, suivez le guide de service de votre plateforme. Ne hot-swappez pas votre patience.
  4. Retirez le dissipateur avec soin. Desserrer en croix un peu à la fois. Évitez de tordre et d’étaler la pâte sur les composants.
  5. Nettoyez complètement les deux surfaces. Utilisez des lingettes/tampons non pelucheux et un solvant approprié. Enlevez l’ancienne pâte des bords et recoins où elle aime se cacher.
  6. Inspectez les surfaces. Recherchez rayures, piqûres, résidus et signes de contact inégal. Confirmez le bon bracket/entretoises pour le socket.
  7. Appliquez la pâte parcimonieusement. Utilisez le minimum nécessaire pour combler les vides : petit point pour un IHS typique, ligne/X pour de grandes empreintes rectangulaires serveur selon le cas.
  8. Placez le dissipateur droit. Évitez de le faire glisser ; un petit déplacement peut créer des vides ou repousser la pâte de façon inégale.
  9. Serrez progressivement en croix. Quelques tours par vis, en alternant les coins, jusqu’à l’assise complète selon la spécification du fournisseur.
  10. Réinstallez chicanes et conduits. Ce n’est pas du décor. C’est la différence entre « système de refroidissement » et « espoir ».
  11. Démarrez et vérifiez les capteurs. Confirmez ventilateurs, température d’entrée et températures CPU dans l’OS et le BMC.
  12. Lancez le test de validation. Comparez à la base. Si les températures sont pires, arrêtez et revérifiez le montage et la quantité de pâte plutôt que « d’essayer un nouveau motif » au hasard.
  13. Enregistrez la modification. Notez le type de pâte, la méthode, et les métriques avant/après. Votre futur vous sera irritablement reconnaissant.

Checklist : sanity du flux d’air et du châssis (avant de blâmer la pâte)

  • Tous les modules ventilateurs présents, bon modèle, pas de défauts signalés.
  • Ailettes du dissipateur propres ; pas de matage de poussière ni de mousse d’emballage (oui, ça arrive).
  • Chicane d’air installée et assise.
  • Panneaux d’obturation en place ; pas de RU ouverts court-circuitant le flux d’air.
  • Faisceaux de câbles ne bloquant pas les entrées des ventilateurs ou la chicane CPU.
  • Températures d’entrée dans la plage attendue ; comparer aux voisins de baie.
  • Profil thermique BMC réglé sur le mode recommandé par le vendeur pour votre charge de travail.

Checklist : choisir la pâte comme un adulte

  • Préférez des pâtes non conductrices et non capacitives pour les serveurs de flotte, sauf si vous avez une raison solide et des contrôles d’exécution.
  • Priorisez la stabilité au cyclage thermique (résistance au pump-out) plutôt que les revendications de conductivité de benchmark maximal.
  • Standardisez sur un ou deux composés approuvés et une méthode d’application par plateforme.
  • Évitez de mélanger les pâtes ou d’appliquer sur des résidus ; nettoyez jusqu’à la surface nue à chaque fois.
  • Si vous utilisez des pads à changement de phase par conception, ne les remplacez pas par de la pâte à la légère ; vous altéreriez un assemblage validé.

FAQ

1) Trop de pâte thermique peut-il réellement aggraver les températures ?

Oui. La pâte sert principalement à combler l’air. Une couche épaisse augmente la résistance thermique comparée au contact métal-métal, élevant les températures et accélérant le bridage.

2) Comment savoir si j’ai mis trop de pâte sans tout démonter ?

Cherchez une signature post-repaste : températures de package plus élevées sous la même charge contrôlée, plus grands deltas par cœur, rampage des ventilateurs plus précoce, et nouveaux événements de throttling dans les logs.
Ces motifs suggèrent fortement une mauvaise interface ou un problème d’assise.

3) La méthode du « pois » est-elle toujours correcte ?

Non. C’est un bon défaut pour beaucoup de tailles d’IHS grand public, mais de grandes empreintes rectangulaires serveur bénéficient souvent d’une ligne ou d’un X pour assurer la couverture des bords. L’exigence réelle est une couverture fine et continue après montage, pas une fidélité à une forme.

4) Faut-il étaler la pâte avec une carte/spatule ?

Dans les opérations de flotte, étaler augmente souvent la variabilité d’épaisseur et peut introduire des bulles si c’est fait à la léger. Un point/ligne/X contrôlé avec une pression de montage appropriée est généralement plus constant. Si vous étalez, utilisez une méthode qui contrôle l’épaisseur et évite l’air.

5) À quelle fréquence faut-il repaster les serveurs ?

Moins souvent que ce que suggèrent les forums hobby. Beaucoup d’assemblages serveur tiennent des années sans repaste. Repastez quand vous avez une preuve : températures qui montent avec le temps, après retrait du dissipateur, ou après un problème de contact vérifié — pas comme rituel saisonnier.

6) Les composés « métal » ou « métal liquide » valent-ils le coup en production ?

Généralement non, sauf si vous avez un process contrôlé et que la plateforme le supporte. Les TIM conducteurs augmentent le risque : courts-circuits, corrosion, et retouches plus difficiles.
La fiabilité prime sur quelques degrés.

7) Mon CPU est chaud ; cela signifie-t-il automatiquement que la pâte est mauvaise ?

Pas automatiquement. Vérifiez d’abord les températures d’entrée, le RPM des ventilateurs, les chicanes et la politique BMC. Les problèmes de flux d’air sont fréquents et affectent plusieurs composants, pas seulement le package CPU.

8) Pourquoi je vois du throttling sans alarme de température évidente ?

Le throttling peut être déclenché par des points chauds localisés ou des capteurs internes qui ne correspondent pas au capteur que vous regardez. De plus, le firmware peut brider de façon proactive en dessous des seuils « critiques ». Utilisez à la fois les logs OS et les capteurs BMC pour une image plus complète.

9) Quel est le facteur mécanique le plus important après la quantité de pâte ?

La pression et l’uniformité de montage. Une pâte parfaite ne compensera pas un dissipateur incliné, serré de façon inégale, ou utilisant la mauvaise entretoise/plaque arrière.

10) Si je repaste et que les températures s’améliorent, suis-je bon ?

Vous êtes bon quand vous avez validé sous une charge soutenue représentative et enregistré le résultat. Beaucoup de problèmes thermiques apparaissent avec le temps, pas dans la première minute.

Conclusion : prochaines étapes concrètes

La pâte thermique n’est pas magique et n’est pas un projet d’artisanat. C’est une interface contrôlée dans un système de transfert thermique avec des modes de panne connus : trop épaisse, assise inégale,
mauvais matériau, ou blâmer le TIM pour des péchés d’aéraulique. Les repastes les plus salissants viennent souvent de la même cause que les pannes bruyantes : changer des choses sans mesurer.

Prochaines étapes pratiques :

  • Choisissez une charge de validation standard et enregistrez les thermiques et fréquences de base pour chaque plateforme.
  • Quand les thermiques dérivent, suivez le cahier de jeu de diagnostic rapide avant de toucher au matériel.
  • Si vous devez repaster, standardisez le type de pâte, la méthode d’application et la séquence de couple — et documentez cela comme tout autre changement en production.
  • Après retouche, validez sous une charge soutenue réaliste, pas seulement « ça boot ».
  • Traitez les régressions thermiques comme des risques de fiabilité, surtout sur des nœuds de stockage effectuant des rebuilds et scrubs.

Si vous retenez une chose : la bonne quantité de pâte est la quantité minimale qui rend l’air négligeable. Tout ce qui dépasse, c’est juste décorer un problème de chaleur.

← Précédent
ZFS Resilver : Pourquoi la reconstruction prend des jours (et comment l’accélérer en toute sécurité)
Suivant →
ZFS ZED : alertes qui vous préviennent d’une panne avant vos utilisateurs

Laisser un commentaire