Rien ne fait tressauter un ingénieur stockage comme un benchmark qui commence fort, puis s’effondre lentement vers la médiocrité. Votre grappe NVMe affichait des performances héroïques pendant 30 secondes, puis les écritures se transforment en une fine bruine. Les graphiques ressemblent à une falaise de plage : plateau élevé, puis triste glissade.
Sur Debian 13, ce n’est souvent pas « Debian qui est lent ». C’est la physique, le firmware et la politique d’alimentation. La limitation thermique (CPU, NVMe, HBA, chipset) réduit en silence la fréquence, la vitesse de lien ou la profondeur des files d’attente, et votre débit s’effondre avec elle. L’astuce consiste à le prouver proprement, puis à réparer sans cuire le matériel ni faire sauter les disjoncteurs.
Playbook de diagnostic rapide
Si vous êtes d’astreinte et que l’équipe stockage regarde un graphique de débit vacillant, vous n’avez pas le temps pour des danses interprétatives. Vous avez besoin d’une séquence qui trouve le goulot d’étranglement rapidement.
Première étape : confirmez que c’est dépendant du temps et corrélé à la température
- Lancez une charge constante (fio ou la relecture de votre charge réelle) pendant au moins 5–10 minutes. Le throttling adore « après la mise en température ».
- Surveillez la fréquence CPU + les compteurs de throttling et la température NVMe en même temps. Si les performances chutent tandis que les températures montent et que des limites s’activent, vous avez une histoire.
Deuxième étape : identifiez quel composant se bride
- Throttling CPU : la fréquence décroche, événements de limite de puissance (PL1/PL2), température package élevée, compteurs « throttled » qui augmentent.
- Throttling NVMe : la température du contrôleur monte, l’état de « thermal management » change, des avertissements SMART apparaissent, la latence grimpe.
- Comportement PCIe/lien : le lien se réentraîne, les compteurs d’erreurs augmentent, la largeur/vitesse négociée chute avec la chaleur.
- Contrôle du refroidissement : les ventilateurs ne montent pas en régime, le BMC coincé en mode « acoustique », le firmware laptop refuse d’accélérer.
Troisième étape : décidez si c’est une politique ou la physique
- Politique : gouverneur powersave, limites d’alimentation trop basses, presets BIOS « écoénergétiques », profils plateforme.
- Physique : poussière, entrée d’air bouchée, dissipateurs NVMe manquants, pâte thermique dégradée, ventilateur mort, mauvais mapping des zones de ventilation.
Faites ces trois étapes et vous arrêterez de débattre « Debian vs noyau vs système de fichiers » et commencerez à débattre de la chose qui chauffe réellement, ce qui est un progrès.
À quoi ressemble le throttling dans le débit réel
La limitation thermique n’est pas subtile. Elle paraît subtile si vous ne mesurez qu’une seule chose.
Schéma classique :
- fio démarre à, disons, 6–7 GB/s en lecture sur un ensemble NVMe en striping.
- Après 60–180 secondes, le débit glisse vers 3–4 GB/s.
- La latence augmente. Les profondeurs de file n’aident plus.
- La fréquence CPU baisse de quelques centaines de MHz, ou la température du contrôleur NVMe franchit un seuil, ou les deux.
Puis vous arrêtez le test, le système refroidit, et le test suivant « a miraculeusement » l’air bon de nouveau. Voilà pourquoi le throttling survit longtemps en production : les benchmarks courts et les reproductions rapides ne le captent pas.
Une citation à garder : Werner Vogels, CTO d’Amazon : « Tout échoue, tout le temps. » (idée paraphrasée). Le throttling est un mode de défaillance qui ressemble à une régression de performance jusqu’à ce que vous l’instrumentiez comme un problème de fiabilité.
Faits intéressants et contexte (parce que l’histoire se répète)
- Intel a introduit un comportement turbo agressif il y a des années, et « rapide à court terme, plus lent à long terme » est devenu la norme : boosts PL2, maintien PL1.
- Les disques NVMe ont des états formels de gestion thermique (souvent deux niveaux), et beaucoup de modèles grand public sont réglés pour throttler tôt en cas de mauvais flux d’air.
- Les centres de données conçus pour les disques tournants ont vu l’augmentation de densité NVMe élever considérablement la chaleur par unité de rack, et les hypothèses d’écoulement d’air ont cassé.
- Le scaling de fréquence CPU sous Linux a connu plusieurs ères (acpi-cpufreq, intel_pstate, amd_pstate), et les valeurs par défaut ont changé ; « ça marchait sur Debian X » n’est pas une preuve.
- Les limites RAPL ont été conçues pour le contrôle d’énergie et sont exposables via des MSR ; les vendeurs définissent parfois des valeurs conservatrices pour respecter l’acoustique ou les cibles thermiques.
- Certains profils BIOS échangent performance soutenue contre bruit ; « Balanced » signifie souvent « silencieux jusqu’à ce que ça fasse mal ».
- Les taux d’erreurs PCIe peuvent augmenter avec la température ; le signal marginal se dégrade avec la chaleur, et le réentraînement du lien peut réduire la bande passante effective.
- La dégradation de la pâte thermique est réelle ; la pâte s’expulse avec des cycles thermiques au fil des années, augmentant la température de jonction pour une même charge.
- Les laptops ont popularisé des heuristiques de throttling agressives (température de la peau, protection de la batterie), et ces idées ont fuité vers les serveurs petit format et les équipements de périphérie.
Prouvez-le : instrumentation valable en post‑mortem
« C’est du throttling » n’est pas une affirmation ; c’est un ensemble de compteurs, températures et séries temporelles. Votre objectif est une seule chronologie où :
- La charge reste constante.
- La performance se dégrade.
- Un état thermique/limite d’alimentation change en même temps.
C’est ainsi que vous gagnez des discussions avec les fournisseurs, votre équipe, et la partie de votre cerveau qui veut que le problème soit « un paramètre ».
Aussi : ne collectez pas tout. Collectez les bonnes choses. Pour le CPU : fréquence, température package, compteurs de throttling, limites de puissance. Pour NVMe : température du contrôleur et événements thermiques. Pour le refroidissement plateforme : RPM des ventilateurs et températures des capteurs. Pour le stockage : distributions de latence, pas seulement le débit.
Blague #1 : la limitation thermique, c’est votre serveur qui vous dit poliment « je suis fatigué » juste avant de commencer à faire la moitié du travail pour le même salaire.
Tâches pratiques : commandes, sorties et décisions
Ce sont des tâches de qualité production. Chacune inclut : la commande, un exemple de sortie, ce que ça signifie et la décision à prendre. Exécutez-les pendant une charge soutenue, pas au repos. Si possible, ouvrez deux terminaux : un pour la charge, un pour la télémétrie.
Tâche 1 : Confirmer le noyau et les bases plateforme
cr0x@server:~$ uname -a
Linux server 6.12.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.0-1 (2025-10-01) x86_64 GNU/Linux
Ce que ça signifie : Vous êtes sur la branche noyau Debian 13 et la version spécifique est enregistrée. Le comportement de throttling peut changer avec les pilotes cpufreq et les ajustements du scheduler.
Décision : Conservez cette chaîne dans vos notes d’incident. Si vous modifiez plus tard le BIOS ou le firmware, vous voudrez contrôler les variables.
Tâche 2 : Vérifier le gouverneur CPU et le pilote (vérification de politique)
cr0x@server:~$ cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
hardware limits: 400 MHz - 5300 MHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 5300 MHz.
The governor "powersave" may decide which speed to use
current CPU frequency: 1200 MHz (asserted by call to hardware)
Ce que ça signifie : intel_pstate + powersave peut convenir pour beaucoup de charges, mais c’est suspect quand le débit chute sous charge soutenue.
Décision : Si vous diagnostiquez une régression de débit, forcez temporairement performance pour éliminer la politique comme variable (plus loin nous verrons la correction durable).
Tâche 3 : Forcer le gouverneur CPU sur performance (test temporaire)
cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Ce que ça signifie : Vous avez éliminé une source fréquente de « baisse mystérieuse ».
Décision : Relancez la même charge et voyez si la baisse persiste. Si la baisse disparaît, vous venez de trouver un problème de politique (ou vous avez masqué un problème thermique en finissant plus vite — continuez la lecture).
Tâche 4 : Installer et utiliser turbostat pour attraper le throttling CPU
cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Reading package lists... Done
cr0x@server:~$ sudo apt-get install -y linux-cpupower linux-tools-common linux-tools-amd64
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
linux-cpupower linux-tools-amd64 linux-tools-common
cr0x@server:~$ sudo turbostat --Summary --interval 2
Summary: 2.00 sec samples
PkgTmp Bzy_MHz Avg_MHz Busy% IRQ SMI PkgWatt CorWatt GFXWatt
93 2800 2200 84.0 12000 0 150.2 120.8 0.0
Ce que ça signifie : La température package est élevée (93°C). Si vous voyez un effondrement de fréquence alors que Busy% reste élevé, c’est un throttling thermique/power classique. Sur certaines plateformes turbostat peut aussi afficher des compteurs « Throt » ou des raisons de limite.
Décision : Si la température package approche TJmax et que les performances chutent, le refroidissement ou les limites d’alimentation sont en jeu. Ensuite : corrélez avec le débit et les limites de puissance.
Tâche 5 : Prouver la limitation de puissance via les compteurs RAPL (Intel)
cr0x@server:~$ sudo apt-get install -y msr-tools
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
msr-tools
cr0x@server:~$ sudo modprobe msr
cr0x@server:~$ sudo rdmsr -a 0x610
00000000dd8080c8
00000000dd8080c8
00000000dd8080c8
00000000dd8080c8
Ce que ça signifie : MSR 0x610 est souvent PKG_POWER_LIMIT. Il faut décoder pour interpréter la puissance/les fenêtres temporelles ; la valeur brute est une preuve et peut être décodée avec des outils/scripts si vous standardisez en interne.
Décision : Si votre organisation ne décode pas encore les limites RAPL, faites-le. Si les limites sont étonnamment basses par rapport à la classe TDP du CPU, suspectez un profil BIOS ou des caps vendeur.
Tâche 6 : Vérifier l’état amd_pstate (systèmes AMD)
cr0x@server:~$ cat /sys/devices/system/cpu/amd_pstate/status
active
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
Ce que ça signifie : amd_pstate actif, mais le gouverneur est powersave. Cela peut convenir; cela peut aussi être excessivement conservateur sous des charges soutenues impliquant I/O + compression + checksum.
Décision : Pour le diagnostic, passez en performance et comparez les résultats soutenus. Si les résultats s’améliorent, définissez une politique persistante (section suivante).
Tâche 7 : Surveiller les températures en direct (simple et efficace)
cr0x@server:~$ sudo apt-get install -y lm-sensors
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
lm-sensors
cr0x@server:~$ sudo sensors-detect --auto
# sensors-detect revision 3.6.0
# System: ExampleVendor ServerBoard
# Summary: 3 drivers loaded
cr0x@server:~$ watch -n 2 sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +92.0°C (high = +90.0°C, crit = +100.0°C)
Core 0: +88.0°C (high = +90.0°C, crit = +100.0°C)
nvme-pci-0100
Adapter: PCI adapter
Composite: +78.9°C (low = -20.1°C, high = +84.8°C)
Ce que ça signifie : Le CPU est au‑dessus de « high », le NVMe approche « high ». C’est la configuration pour un throttling double : le CPU réduit le calcul, le NVMe réduit sa propre vitesse, et la latence devient horrible.
Décision : Si les températures approchent « high » pendant une I/O soutenue, considérez le refroidissement comme un goulot principal, pas comme une pensée secondaire.
Tâche 8 : Inspecter les températures SMART NVMe et les événements thermiques
cr0x@server:~$ sudo apt-get install -y nvme-cli smartmontools
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
nvme-cli smartmontools
cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning : 0x00
temperature : 80 C
available_spare : 100%
percentage_used : 2%
thermal_management_t1_trans_count : 7
thermal_management_t2_trans_count : 1
time_for_thermal_management_t1 : 438
time_for_thermal_management_t2 : 55
Ce que ça signifie : Le disque est passé en état de gestion thermique T1 et même T2. C’est du throttling avec papier administratif.
Décision : Si ces compteurs augmentent pendant la fenêtre de chute de débit, arrêtez de blâmer les systèmes de fichiers. Réparez le flux d’air et le refroidissement autour des NVMe.
Tâche 9 : Vérifier les capteurs de température NVMe via smartctl (vue alternative)
cr0x@server:~$ sudo smartctl -a /dev/nvme0
smartctl 7.4 2024-12-08 r5560 [x86_64-linux-6.12.0-1-amd64] (local build)
=== START OF INFORMATION SECTION ===
Model Number: ExampleNVMe 3.84TB
Firmware Version: 2B0QEXM7
=== START OF SMART DATA SECTION ===
Temperature: 80 Celsius
Temperature Sensor 1: 82 Celsius
Temperature Sensor 2: 76 Celsius
Warning Comp. Temperature Time: 438
Critical Comp. Temperature Time: 55
Ce que ça signifie : Les compteurs de temps en température d’avertissement et critique sont non nuls et augmentent. Cela corrèle fortement avec le throttling et parfois avec une accélération de l’usure des médias.
Décision : Traitez la température NVMe comme vous traitez les erreurs mémoire : un signal de fiabilité, pas seulement de « performance ».
Tâche 10 : Vérifier la vitesse/largeur de lien PCIe négociée (la chaleur peut révéler la marginalité)
cr0x@server:~$ sudo lspci -s 01:00.0 -vv | sed -n '/LnkCap:/,/LnkSta:/p'
LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (downgraded), Width x4 (ok)
Ce que ça signifie : Le lien peut faire 16GT/s mais est actuellement à 8GT/s. Cela peut arriver à cause de paramètres BIOS, intégrité du signal, ou parfois récupération d’erreur liée à la chaleur.
Décision : Si vous voyez un lien dégradé pendant la phase « lente », examinez les erreurs PCIe et l’installation physique (riser, câble, slot, flux d’air). Corriger cela peut doubler la bande instantanément.
Tâche 11 : Rechercher des erreurs PCIe qui s’alignent avec la chaleur et le throttling
cr0x@server:~$ sudo dmesg -T | egrep -i 'aer|pcie|nvme|thrott'
[Mon Dec 29 11:04:12 2025] pcieport 0000:00:1d.0: AER: Corrected error received: 0000:01:00.0
[Mon Dec 29 11:04:12 2025] nvme 0000:01:00.0: AER: can't recover (no error_detected callback)
[Mon Dec 29 11:05:01 2025] nvme nvme0: I/O 123 QID 4 timeout, aborting
Ce que ça signifie : Même les erreurs PCIe corrigées peuvent dégrader les performances ; les timeouts sont pires. La chaleur peut faire mal se comporter les liens limites.
Décision : Si les erreurs augmentent pendant la charge soutenue et que les températures sont élevées, réglez le flux d’air/slot/câblage, et mettez à jour le firmware. Ne « tunez pas autour » d’un lien flaky.
Tâche 12 : Mesurer le débit et la latence de façon à attraper le throttling (série temporelle fio)
cr0x@server:~$ sudo apt-get install -y fio
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
fio
cr0x@server:~$ fio --name=warmth --filename=/dev/nvme0n1 --direct=1 --ioengine=io_uring --rw=read --bs=128k --iodepth=32 --numjobs=1 --runtime=600 --time_based=1 --group_reporting=1 --status-interval=10
warmth: (groupid=0, jobs=1): err= 0: pid=22114: Mon Dec 29 11:07:10 2025
read: IOPS=52.1k, BW=6512MiB/s (6827MB/s)(63.6GiB/10s)
...
warmth: (groupid=0, jobs=1): err= 0: pid=22114: Mon Dec 29 11:09:20 2025
read: IOPS=34.0k, BW=4250MiB/s (4457MB/s)(41.5GiB/10s)
...
warmth: (groupid=0, jobs=1): err= 0: pid=22114: Mon Dec 29 11:17:10 2025
read: IOPS=33.2k, BW=4149MiB/s (4350MB/s)(40.5GiB/10s)
Ce que ça signifie : Même job, mêmes paramètres, le débit est tombé et est resté bas. C’est une limitation soutenue, pas un bruit aléatoire.
Décision : Quand vous voyez un comportement en paliers, corrélez immédiatement les horodatages avec turbostat/sensors/nvme smart-log. Si la corrélation est forte, arrêtez de modifier les flags fio. Commencez à réparer le refroidissement/l’alimentation.
Tâche 13 : Observer les statistiques de la couche bloc et des files d’attente du périphérique (est‑ce que le périphérique cale ?)
cr0x@server:~$ iostat -dxm 2 5 nvme0n1
Linux 6.12.0-1-amd64 (server) 12/29/2025 _x86_64_ (64 CPU)
Device r/s rMB/s rrqm/s %rrqm r_await rareq-sz aqu-sz %util
nvme0n1 52000.0 6500.0 0.0 0.00 0.60 128.0 31.0 99.0
nvme0n1 34000.0 4250.0 0.0 0.00 0.95 128.0 32.0 99.0
Ce que ça signifie : %util reste élevé tandis que le débit chute et que l’await augmente. Le périphérique est le limiteur (ou le chemin vers lui), pas le CPU qui le prive de requêtes.
Décision : Orientez votre lampe torche vers la température NVMe, l’état du lien PCIe et le refroidissement physique.
Tâche 14 : Vérifier le journal systemd pour des indices thermiques/puissance
cr0x@server:~$ sudo journalctl -k -b | egrep -i 'thermal|thrott|powercap|rapl|cpu frequency' | tail -n 20
Dec 29 11:04:55 server kernel: intel_rapl_common: Found RAPL domain package
Dec 29 11:05:03 server kernel: CPU0: Core temperature above threshold, cpu clock throttled
Dec 29 11:05:03 server kernel: CPU2: Core temperature above threshold, cpu clock throttled
Ce que ça signifie : Le noyau vous dit littéralement qu’il a throttlé. Croyez‑le.
Décision : Prenez cela comme confirmation, puis corrigez les causes racines : flux d’air, dissipateurs, commande des ventilateurs, ou profil d’alimentation.
Tâche 15 : Sur serveurs, vérifier les capteurs IPMI et le comportement des ventilateurs
cr0x@server:~$ sudo apt-get install -y ipmitool
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
ipmitool
cr0x@server:~$ sudo ipmitool sensor | egrep -i 'fan|temp|inlet|exhaust|cpu'
Inlet Temp | 29.000 | degrees C | ok
Exhaust Temp | 51.000 | degrees C | ok
CPU1 Temp | 92.000 | degrees C | ok
FAN1 | 1800.000 | RPM | ok
FAN2 | 1700.000 | RPM | ok
Ce que ça signifie : Le CPU est chaud, mais les ventilateurs ne hurlent pas. C’est souvent un problème de politique de contrôle (mode silencieux, mauvais mapping capteur) ou un blocage physique.
Décision : Escaladez pour ajuster le profil BIOS/BMC. Si vous ne contrôlez pas ça, impliquez la personne responsable du firmware plateforme. Le logiciel seul ne fera pas tourner les ventilateurs plus vite si le BMC n’est pas d’accord.
Tâche 16 : Vérification rapide pour les services « utiles » en arrière‑plan (tlp/power-profiles-daemon)
cr0x@server:~$ systemctl status power-profiles-daemon.service --no-pager
● power-profiles-daemon.service - Power Profiles daemon
Loaded: loaded (/lib/systemd/system/power-profiles-daemon.service; enabled)
Active: active (running) since Mon 2025-12-29 10:52:11 UTC; 25min ago
Ce que ça signifie : Un daemon peut pousser un comportement « balanced ». Sur les laptops, c’est normal. Sur des nœuds stockage, c’est souvent un tueur silencieux de débit.
Décision : Décidez explicitement : nœud performance ou non. Si oui, verrouillez le profil performance et documentez‑le. Si non, acceptez le plafond de débit.
Throttling spécifique au stockage : NVMe, PCIe, et « pourquoi fio ment »
Le débit stockage est une chaîne : le CPU soumet l’I/O, le noyau la met en file, le PCIe la transporte, le contrôleur la sert, la NAND fait le travail, et le contrôleur essaie de ne pas fondre. On peut brider à n’importe quelle étape.
Le throttling NVMe est généralement un problème de contrôleur, pas de NAND
Le contrôleur NVMe est le point chaud. La NAND tolère la chaleur jusqu’à un certain point, mais le silicium et l’emballage du contrôleur non. Beaucoup de disques rapportent une température « Composite », mais aussi plusieurs capteurs. Si le capteur 1 monte pendant que le Composite traîne, vous regardez le contrôleur griller.
Les transitions de gestion thermique (T1/T2) sont l’arme fumante car elles sont comptées. Si vous pouvez montrer que thermal_management_t1_trans_count s’incrémente au même instant que votre débit chute, vous avez prouvé le cas avec la propre paperasse du disque.
Pourquoi les benchmarks courts passent à côté
Parce que le disque démarre frais, les modes turbo sont actifs, le cache SLC est généreux, et le contrôleur n’a pas encore saturé sa masse thermique. Ensuite il chauffe. Puis le firmware bride. La première minute est le mensonge que vous vous racontez.
La vitesse du lien PCIe et ASPM peuvent être des faux‑amis — ou toute l’histoire
Si votre lien PCIe est négocié à une vitesse inférieure, vous pouvez limiter le débit indépendamment des capacités du disque. Parfois c’est de la configuration, parfois c’est la récupération d’erreur. Parfois c’est la qualité du riser/câble. Parfois c’est « quelqu’un a installé un périphérique x4 dans un slot qui partage des lanes avec trois autres, et maintenant la topologie nous rattrape ».
ASPM (économie d’énergie) peut provoquer des micro‑couacs de latence, mais il cause rarement une chute nette et soutenue de débit à lui seul. Les limites thermiques et de puissance le font.
Throttling CPU et stockage : le couplage désagréable
Vous pourriez penser que le stockage est « I/O bound » et que la fréquence CPU n’a pas d’importance. Puis vous activez checksums, compression, chiffrement, codage d’effacement ou des charges IOPS élevées en petits blocs. Soudainement le CPU fait un vrai travail par I/O, et la fréquence compte. Le throttling devient moins d’IOPS, une latence de queue élevée, et parfois des récits étranges du type « le périphérique est lent ».
Blague #2 : si vous voulez simuler le throttling thermique en réunion, présentez votre graphe puis baissez lentement la voix jusqu’à ce que tout le monde s’ennuie.
Corrections qui font vraiment la différence : refroidissement, flux d’air et contact
Les corrections de refroidissement sont peu glamour. Elles fonctionnent aussi. Si vous voulez du débit soutenu, il vous faut une marge thermique soutenue. Pas « ça passe un test de 30 secondes ». Soutenu.
1) Arrêtez de recirculer l’air chaud
La plupart des « throttlings mystères » dans les racks viennent du flux d’air. Le serveur aspire son propre échappement parce que :
- Les panneaux de remplissage sont manquants.
- La containment du couloir chaud est… théorique.
- Les câbles bloquent l’admission ou créent de la turbulence.
- Le serveur est poussé dans un emplacement avec une mauvaise livraison d’air froid.
Mesurez l’entrée vs l’échappement via IPMI. Si l’entrée est déjà élevée avant la charge, vous opérez avec moins de marge.
2) Assurez-vous que les ventilateurs montent en régime quand il le faut
Sur beaucoup de serveurs, Linux ne peut pas commander directement les ventilateurs ; le BMC le fait. Si le BMC est en profil silencieux, il laissera volontiers le CPU atteindre la limite et throttler, car il optimise l’acoustique et la longévité des composants. Votre travail est d’optimiser le débit et la prédictibilité.
La correction se trouve généralement dans les réglages BIOS/BMC : profil thermique « Performance », minimums ventilateur plus élevés, ou mapping capteurs correct. Si vous ne pouvez pas le changer, documentez‑le au moins, car vous vivez dans les hypothèses de quelqu’un d’autre.
3) Les dissipateurs NVMe et le flux d’air comptent plus que vous ne le pensez
Les M.2 NVMe dans les serveurs sont un piège classique. Nés pour les laptops où le flux d’air est minimal mais le châssis intégré, en serveur on monte souvent un M.2 « parce que ça rentre », puis on s’étonne qu’il throttle. Les baies U.2/U.3 ont généralement un meilleur flux d’air, mais même là, les baies frontales denses chauffent.
Actions concrètes :
- Ajouter des dissipateurs adaptés (qualifiés par le vendeur si vous voulez préserver la garantie).
- Ajouter des guides/shrouds de flux d’air si le châssis les supporte.
- Veiller à ce que des périphériques très chauds adjacents (GPU, DPU, HBA) ne déversent pas de chaleur dans la même zone.
4) Reseat et repast (oui, vraiment)
Au fil des années, la pâte thermique peut se dégrader. La pression de montage peut bouger. La poussière isole. J’ai vu des « régressions logicielles » disparaître après nettoyage d’un dissipateur qui ressemblait à un filtre.
Quand le faire :
- Un nœud sur un pool throttle plus tôt que ses pairs.
- Les ventilateurs se comportent normalement, mais la température CPU monte plus vite que prévu.
- Des problèmes de contact dissipateur sont plausibles (maintenance récente, transport, vibration).
Soyez disciplinés : planifiez une fenêtre, suivez les pratiques ESD, utilisez une pâte connue, et vérifiez ensuite avec la même instrumentation.
Corrections pour les limites d’alimentation : RAPL, amd_pstate et menottes firmware
Le throttling thermique et la limitation de puissance sont des cousins qui partagent les vêtements. Vous pouvez être limité en puissance bien avant d’être au maximum thermique, surtout sur des serveurs configurés pour « l’efficacité » ou des budgets d’alimentation contraints.
Gouverneurs CPU et profils plateforme : ne laissez pas les valeurs par défaut gérer vos nœuds stockage
Les valeurs par défaut sont conçues pour des systèmes polyvalents. Les nœuds stockage sous I/O soutenue ne le sont pas. Si vous voulez des performances prévisibles, définissez une politique explicite :
- Gouverneur CPU : performance (ou au moins un réglage adapté qui évite un fort downclock sous charge).
- Profil plateforme : performance (si supporté).
- Désactiver les daemons orientés laptop sur les serveurs sauf raison justifiée.
Configuration persistante du gouverneur (systemd)
Pour Debian, une approche propre est une petite unité systemd qui fixe le gouverneur au démarrage. C’est brut, mais honnête. Vous pouvez aussi utiliser cpufrequtils, mais systemd rend l’intention explicite et versionnée.
cr0x@server:~$ sudo tee /etc/systemd/system/cpupower-performance.service <<'EOF'
[Unit]
Description=Set CPU governor to performance
After=multi-user.target
[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set -g performance
[Install]
WantedBy=multi-user.target
EOF
cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl enable --now cpupower-performance.service
Created symlink /etc/systemd/system/multi-user.target.wants/cpupower-performance.service → /etc/systemd/system/cpupower-performance.service.
Décision : N’appliquez ceci que sur les nœuds où la performance soutenue compte et où vous comprenez l’impact sur l’alimentation/thermique. Sinon vous « corrigerez le débit » en consommant plus, puis vous retrouverez les limites de refroidissement.
Intel RAPL : ne montez pas les limites aveuglément
Le tuning RAPL peut être efficace, mais c’est aussi la façon de transformer un « throttling prévisible » en « arrêts imprévisibles » si le refroidissement ne suit pas. Si vous augmentez PL1/PL2 sans corriger le flux d’air, vous déplacez simplement le point de défaillance.
Ce que vous devriez faire à la place :
- Fixer d’abord le refroidissement/profil ventilateur pour supporter la charge soutenue.
- Valider ensuite la puissance package soutenue et la température sous la charge réelle.
- Only then consider adjusting limits, and keep changes small and reversible.
Systèmes AMD : pstate + CPPC peuvent bien fonctionner, jusqu’à ce que le firmware devienne conservateur
amd_pstate a tendance à bien se comporter, mais vous pouvez quand même être plafonné par des limites plateforme (PPT/TDC/EDC) et des contraintes thermiques. La voie de correction est souvent un réglage BIOS (profil performance, limites thermiques, courbes ventilateur), pas des flags Linux seuls.
Erreurs courantes : symptôme → cause racine → correction
Cette section existe parce que les humains répètent les erreurs avec conviction.
1) Le débit chute après 1–3 minutes, puis se stabilise bas
Cause racine : Throttling thermique NVMe (T1/T2), souvent dû à un mauvais flux d’air/contacter le dissipateur.
Correction : Ajouter dissipateurs/guides d’air, s’assurer que les ventilateurs montent, éloigner les disques des sources de chaleur, valider avec les compteurs nvme smart-log.
2) Les IOPS chutent alors que Busy% CPU reste élevé, température CPU proche du seuil
Cause racine : Throttling CPU thermique ou limitation de puissance (PL1 clampant la fréquence soutenue).
Correction : Corriger d’abord le refroidissement (ventilateurs/profil/dissipateur), puis vérifier le gouverneur et le profil BIOS d’alimentation. Utiliser turbostat + logs pour preuve.
3) La performance est correcte au cold boot, mauvaise après une mise à jour firmware
Cause racine : BIOS réinitialisé sur profil « Balanced » ou « Acoustic » ; limites d’alimentation modifiées ; courbe ventilateur changée.
Correction : Rétablir les réglages BIOS/BMC connus bons. Traitez les mises à jour firmware comme des changements de configuration avec une checklist.
4) Un nœud d’une flotte est plus lent avec une configuration identique
Cause racine : Variation physique : poussière, ventilateur défaillant, pâte dégradée, dissipateur mal assis, baffle d’air manquant.
Correction : Comparez les baselines IPMI entre nœuds, inspectez le hardware, nettoyez et repastez si nécessaire.
5) Pics de latence, dmesg montre des erreurs AER corrigées
Cause racine : Lien PCIe marginal (riser/câble/slot) exacerbé par la température ; le lien peut se réentraîner vers le bas.
Correction : Reseat/remplacer riser, changer de slot, mettre à jour le firmware, améliorer le flux d’air autour de la zone PCIe, confirmer la vitesse négociée.
6) Après « optimisation de l’énergie », le stockage est devenu plus lent
Cause racine : Gouverneur/profil d’alimentation trop conservateur ; états C profonds ou downclocking ajoutent de la latence et plafonnent les IOPS.
Correction : Définir une politique performance explicite sur les nœuds stockage ; mesurer la consommation et les températures ; ne pas optimiser l’énergie sans SLOs.
7) fio affiche de grands chiffres, l’application est lente
Cause racine : Le benchmark n’est pas représentatif : trop court, mauvaise profondeur de file, effets de cache, pas soutenu, ou ne mesure pas la latence de queue.
Correction : Lancer des tests soutenus (10+ minutes), logger températures et événements de throttling, et mesurer p95/p99 de latence dans votre application.
Trois micro‑histoires du monde corporate
Micro‑histoire 1 : L’incident causé par une mauvaise hypothèse
Une entreprise exploitait des nœuds stockage qui ingéraient des logs. Rien d’exotique : NVMe, Linux, pipeline simple. Une nouvelle livraison de serveurs est arrivée, même nom de modèle, « pareil que la fois précédente ». L’équipe les a imageés, intégrés au cluster, et est rentrée satisfaite.
Deux jours plus tard, le retard d’ingestion augmentait chaque après‑midi. Pas une panne nette, juste une dérive lente vers « pourquoi sommes‑nous à la traîne ? » Les graphiques insultaient : tout allait bien le matin. À midi, le débit fléchissait, la latence montait, et l’arriéré grossissait. On a blâmé le pipeline, puis l’application, puis le réseau.
La mauvaise hypothèse était simple : « même nom de modèle = même comportement thermique ». Les nouveaux serveurs livraient un carrier NVMe différent et une disposition de baffle d’air différente. Sur l’ancien modèle, l’air front‑to‑back balayait la zone NVMe. Sur le nouveau, le contrôleur NVMe se retrouvait dans une poche d’air chaud derrière une barrière plastique qui avait l’air inoffensive jusqu’à mesure.
Ils l’ont prouvé avec deux chronologies : lectures soutenues fio et compteurs de gestion thermique NVMe. Chaque fois que l’arriéré augmentait, le thermal_management_t1_trans_count cochaait en synchronisation. La correction n’était pas ingénieuse. Elle était physique : installer le kit de baffle correct, mettre les ventilateurs en profil « performance » du vendeur, et ajouter des dissipateurs pour les disques les plus chauds.
Après le changement, la baisse de l’après‑midi a disparu. Le postmortem a été franc : ils avaient traité la variance plateforme comme non pertinente. L’action a été claire : baseliner les thermiques lors de l’acceptation matérielle, pas après les cris en production.
Micro‑histoire 2 : L’optimisation qui s’est retournée
Une autre organisation a cherché sérieusement à économiser de l’énergie. Bon motif, coûts réels. Ils ont déployé une configuration « verte » dans la flotte : gouverneur équilibré, plateforme en mode économie d’énergie, et réglages agressifs autour des comportements inactifs. Le tableau de bord énergétique était beau.
Puis leurs jobs batch nocturnes ont commencé à durer plus longtemps. Pas catastrophiquement plus longtemps — juste assez pour chevaucher le pic du matin. Ce chevauchement a causé une latence visible par les utilisateurs. L’incident a été lent, politique et pénible : chacun avait un graphique qui soutenait sa narrative favorite.
L’optimisation a échoué car ils ont optimisé la mauvaise phase du jour. Le système passait beaucoup d’heures en charge modérée et en rafales courtes, où les économies étaient réelles. Mais pendant de longues I/O soutenues avec compression, le CPU était saturé. La politique « balanced » réduisait la fréquence plus agressivement que prévu, et des limites de puissance soutenues empêchaient le CPU de maintenir des fréquences plus hautes. Ce n’était pas juste « CPU plus lent ». C’était « CPU plus lent pendant la fenêtre exacte où nous avions besoin de débit soutenu ».
Ils l’ont prouvé en capturant turbostat pendant le batch : chute de fréquence avec Busy% élevé, plus des logs kernel indiquant un throttling d’horloge. Les graphiques de débit stockage suivaient la courbe de fréquence presque embarrassante. Les NVMe n’étaient pas le goulot ; le calcul par I/O l’était.
La correction a été de séparer les politiques : conserver l’économie d’énergie sur les nœuds généraux, mais verrouiller les nœuds stockage/batch sur un profil performance pendant les fenêtres batch. Cela a demandé du processus, pas des héros : changement contrôlé, documentation, et un service boot simple pour définir le gouverneur. La consommation a légèrement augmenté. Les incidents ont beaucoup diminué.
Micro‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une équipe finance exploitait un cluster de stockage modeste sous ZFS. Ils n’étaient pas tape‑à‑l’œil, mais disciplinés. Chaque trimestre, après patch, ils réalisaient un « soak test » de performance soutenue : 30 minutes de charge lecture/écriture, avec températures et compteurs de throttling collectés et archivés.
Un trimestre, le soak a montré un truc : le débit était correct les premières minutes, puis tombait d’un tiers environ. L’application allait bien, le noyau avait été mis à jour, et personne ne s’était encore plaint. En d’autres termes : le moment parfait pour trouver un problème, parce que l’entreprise ne criait pas encore.
Ils ont comparé la télémétrie du soak au trimestre précédent et vu deux différences : la température CPU augmentait plus vite, et le RPM ventilateur BMC plafonnait plus bas. Une mise à jour firmware avait silencieusement réinitialisé le profil ventilateur. Rien « n’a cassé », donc ce n’était pas évident. Mais le soak l’a rendu évident.
Ils ont remis le profil BMC en performance, relancé le soak, et la baisse a disparu. Pas d’incident. Pas de panique. Juste une case cochée et un rerun.
Le manager de l’équipe a appelé ça « l’excellence ennuyeuse », qui est le plus beau compliment qu’on puisse faire aux opérations. Le test ne les a pas rendus meilleurs en héroïsme ; il a rendu l’héroïsme inutile.
Listes de contrôle / plan étape par étape
Étape par étape : prouver le throttling de bout en bout (méthode répétable)
- Choisir une charge soutenue : 10–20 minutes, paramètres constants. Éviter les tests « burst ».
- Démarrer la charge avec sortie d’état : fio avec
--status-interval. - En parallèle, collecter la télémétrie CPU : turbostat toutes les 2 secondes.
- En parallèle, collecter les températures : sortie
sensorsen watch. - En parallèle, collecter les compteurs thermiques NVMe : snapshot smart-log début/milieu/fin.
- Marquer les horodatages : noter l’heure ou logger tout dans des fichiers.
- Chercher la corrélation : chute de débit alignée sur hausse de température et preuves de limites thermiques/power.
- Classer le goulot : CPU vs NVMe vs lien PCIe vs contrôle refroidissement.
- Appliquer une correction à la fois : profil ventilateur OU dissipateur OU gouverneur, pas tout en même temps.
- Répéter le même test : comparer les courbes, pas des chiffres isolés.
Checklist refroidissement (serveurs)
- Température d’entrée raisonnable sous charge ? Sinon corriger flux d’air/containment rack.
- Les ventilateurs montent bien avec la température CPU/NVMe ? Sinon régler le profil BMC.
- Panneaux de remplissage présents ? Faisceaux de câbles bloquent l’admission ? Corriger.
- NVMe a des dissipateurs ou un flux d’air ? Sinon, ajouter.
- Un nœud plus chaud que les pairs ? Inspecter : poussière, santé ventilateur, pâte, baffles.
Checklist politique d’alimentation (nœuds Debian 13)
- Confirmer que le gouverneur et le pilote cpufreq correspondent à l’intention.
- Vérifier la présence de daemons de gestion d’énergie sur les serveurs ; retirer ou configurer.
- Valider le profil plateforme/preset BIOS après mise à jour.
- Ne pas augmenter les limites d’alimentation tant que le refroidissement n’est pas prouvé suffisant sous charge soutenue.
FAQ
1) Comment savoir que c’est du throttling thermique et pas le « comportement de cache SSD normal » ?
Recherchez des preuves explicites : compteurs de transition de gestion thermique NVMe (T1/T2) qui augmentent, ou messages CPU « clock throttled », alignés sur la chute de débit. Les effets de cache n’incrémentent généralement pas les compteurs thermiques.
2) Pourquoi mon benchmark a l’air excellent quand je le relance juste après ?
Parce qu’arrêter la charge refroidit le matériel. Vous réinitialisez l’état thermique. Les tests soutenus révèlent le plafond d’état stable ; les courtes relances montrent le plafond de rafale.
3) Est‑ce que le throttling CPU peut vraiment réduire tant le débit stockage ?
Oui, surtout avec compression, checksums, chiffrement, I/O petits blocs à haute IOPS, ou piles stockage en espace utilisateur. Si le CPU ne peut pas soumettre/traiter les complétions d’I/O assez vite, les IOPS chutent.
4) Dois‑je toujours définir le gouverneur CPU sur performance sur les nœuds stockage ?
Sur les nœuds où la performance soutenue est un SLO, oui — après avoir validé le refroidissement et le budget d’alimentation. Sur des nœuds usages mixtes ou thermiquement contraints, préférez une approche équilibrée réglée.
5) Les dissipateurs NVMe sont‑ils toujours nécessaires ?
Pas toujours, mais souvent la manière la moins coûteuse d’éviter le throttling, surtout pour les M.2 ou les baies denses U.2/U.3. Si votre NVMe atteint T1/T2 sous charge soutenue, la réponse est pratiquement « oui ».
6) Mes ventilateurs sont lents mais les températures sont hautes. Linux peut‑il régler ça ?
Parfois sur PC de bureau ; souvent non sur serveurs. Beaucoup de serveurs utilisent le BMC pour contrôler les ventilateurs. Vous aurez besoin de réglages BIOS/BMC, pas d’un paramètre noyau malin.
7) Est‑ce sûr d’augmenter les limites d’alimentation (PL1/PL2) ?
Ça peut l’être, si la plateforme est conçue pour cela et si le refroidissement est vérifié. C’est dangereux si vous êtes déjà proche des limites thermiques ou si le budget électrique du rack est serré. Corrigez d’abord le refroidissement, puis testez.
8) Et si la vitesse du lien PCIe affiche « downgraded » seulement après réchauffement ?
C’est un signe d’intégrité de signal marginale ou de récupération d’erreur sous stress. Vérifiez les erreurs AER, reseate/remplacez les risers, et améliorez le flux d’air autour des périphériques PCIe. Ne l’ignorez pas ; cela peut devenir une instabilité du chemin de données.
9) Pourquoi Debian 13 est‑il blâmé pour ça ?
Parce que les mises à jour d’OS changent les valeurs par défaut (gouverneurs, pilotes, daemons) et coïncident souvent avec des mises à jour firmware. Le timing rend les gens suspicieux. La physique, elle, s’en fiche.
10) Quelle télémétrie archiver pour de futurs débats « ça a ralenti » ?
Sortie fio en continu, résumés turbostat, snapshots sensors, compteurs NVMe smart-log, dumps capteurs IPMI, et logs kernel contenant des messages de throttling ou AER.
Conclusion : prochaines étapes réalisables aujourd’hui
Si votre débit chute dans le temps sur Debian 13, partez du principe que c’est du throttling tant que ce n’est pas prouvé autrement. Non pas parce que Debian est fragile, mais parce que le matériel moderne est agressivement opportuniste : il booste d’abord et négocie ensuite.
Faites ceci dans l’ordre :
- Lancez une charge soutenue de 10–20 minutes et capturez la série temporelle de débit.
- Capturez la température/fréquence CPU et les preuves de throttling (turbostat + journal).
- Capturez les compteurs thermiques NVMe (nvme smart-log, smartctl).
- Si vous corrélez la chute de performance avec des preuves thermiques/power, corrigez d’abord le refroidissement/le profil ventilateur.
- Ce n’est qu’ensuite que vous ajustez la politique d’alimentation (gouverneurs, profil plateforme, et — prudemment — limites de puissance).
- Relancez le même test soutenu et comparez la courbe complète, pas un seul chiffre.
L’objectif est une performance soutenue ennuyeuse. La vitesse de rafale est pour les slides marketing. Le débit en régime permanent est pour la production.