On ne regrette pas les ventilateurs tant qu’on n’a pas déployé quelque chose où les ventilateurs sont la première pièce mobile à lâcher. Ou jusqu’à ce que votre mini-serveur “silencieux” de bureau commence à ressembler à un souffleur de feuilles dès que quelqu’un lance un rapport. Le bruit est agaçant, mais le vrai coût est opérationnel : les roulements s’usent, la poussière obstrue, les capteurs de RPM font n’importe quoi, la marge thermique disparaît et votre machine “stable” devient une petite loterie.
Le calcul passif — des processeurs refroidis sans ventilateurs — est de retour car le silicium moderne est suffisamment efficace, l’ingénierie des châssis est meilleure, et nous avons enfin admis que “ajouter plus de flux d’air” n’est pas une stratégie. C’est une habitude. Parlons des cas où l’absence de ventilateur a du sens, où c’est un piège, et comment exploiter ces systèmes comme des adultes.
Pourquoi le fanless revient (et pourquoi il n’est jamais vraiment parti)
L’histoire principale est l’efficacité. Les CPU qui autrefois restaient chauds comme un “grille-pain tiède” sont maintenant proches du “caillou légèrement jugéant.” Les nœuds de fabrication, la coupure d’alimentation et la gestion d’énergie intégrée sont devenus sérieux. Mais l’histoire plus discrète est que le refroidissement passif n’est plus une nouveauté ; c’est une catégorie produit d’ingénierie : châssis avec caloducs, profils à ailettes, plaques de conduction et boîtiers-froidissants inspirés des équipements industriels et télécoms.
Aussi : nos attentes vis-à-vis du calcul ont changé. Beaucoup de charges sont passées de “un gros serveur chaud” à “beaucoup de petites boîtes faisant bien une tâche.” Ce changement rend le passif viable. Si votre nœud edge exécute quelques conteneurs, un VPN, un cache local et des métriques, vous n’avez pas besoin de 350 W de puissance CPU et d’une ferme de turbines. Vous avez besoin d’une performance prévisible, zéro drame et la capacité de survivre à un placard poussiéreux.
Le retour n’est pas uniquement une question de silence. Il s’agit de fiabilité et de maintenabilité. Un système sans ventilateur a moins de pièces d’usure, moins de modes de panne et moins de tickets surprises à 2 h du matin. L’échange est la marge thermique. Le passif est honnête : il ne prétendra pas être un serveur 1U à fort flux d’air. Si vous le lui demandez, il limitera sa fréquence puis vous le signalera poliment dans le journal du noyau.
La physique à laquelle on ne peut pas déroger : watts, surface et réalité ambiante
Le refroidissement passif est un exercice de budget thermique. Le CPU transforme l’énergie électrique en chaleur (presque toute). Cette chaleur doit passer du silicium au package, au spreader thermique, au dissipateur, à l’air et finalement à la pièce. Les ventilateurs trichent en augmentant la convection ; le passif repose sur la surface, les chemins de conduction et la convection naturelle (plus tout flux d’air accidentel fourni par l’environnement).
Commencez par le seul chiffre qui compte : la puissance soutenue
Le marketing CPU adore les fréquences de boost maximales et les courtes fenêtres turbo. Les designs passifs se préoccupent de la puissance soutenue du package sous des charges réelles à votre température ambiante. L’étiquette “TDP” est un indice, pas un contrat. Beaucoup de CPU acceptent de monter au-dessus pendant des secondes à minutes, puis se stabilisent à une limite long terme jugée sûre par le firmware. Dans les systèmes passifs, ce point de stabilisation se produit plus tôt et plus brutalement.
Vous devez savoir :
- Quelle puissance package le système peut soutenir sans throttling à votre maximum d’ambiante (pas votre bureau, votre pire placard).
- Si le throttling est progressif (une limitation douce) ou violent (scie de fréquence qui ruine la latence).
- Ce qui d’autre injecte de la chaleur dans le châssis : lecteurs NVMe, cartes réseau, VRM, injecteurs PoE, modems, même la RAM à haut taux de rafraîchissement.
La température ambiante est le SLA caché
Les systèmes passifs vivent et meurent par le delta-T : la différence de température entre le dissipateur et l’air. Quand la pièce fait 22°C, la vie est facile. Quand elle fait 35°C, votre marge s’effondre. La même boîte qui fonctionnait sur un banc peut se mettre à throttler dans une armoire parce que l’armoire est effectivement un radiateur avec une porte.
Le matériel sans ventilateur souffre aussi de “stacking” : empilez deux boîtiers passifs l’un sur l’autre, et celui du dessus devient un système refroidi passivement par l’échappement d’un autre système passif. Ce n’est pas un plan de gestion thermique, c’est un travail de groupe.
La conception thermique est une chaîne ; le maillon le plus faible gagne
Dans les déploiements réels, le CPU n’est souvent pas le premier problème. Le premier problème est un lecteur NVMe atteignant son propre point de throttling parce qu’il est sous une plaque de conduction sans flux d’air. Ou une carte 2.5GbE/10GbE qui chauffe et commence à perdre le lien ou à générer des erreurs. Ou des VRM qui montent en température et déclenchent des limites de puissance. Les builds passifs nécessitent une réflexion thermique holistique : CPU + stockage + alimentation + boîtier + emplacement.
Une citation qui tient encore en exploitation : “L’espoir n’est pas une stratégie.” —General Gordon R. Sullivan. Elle s’applique aussi à la conception thermique.
Ce que “CPU sans ventilateur” signifie réellement en 2026
“CPU sans ventilateur” est un raccourci, mais c’est vraiment “conception de système sans ventilateur.” Le CPU seul ne décide pas. Le châssis, la géométrie du dissipateur et les limites firmware le font. Voici les principaux types que vous verrez sur le terrain :
1) x86 dérivé mobile (faible consommation, étonnamment capable)
Ce sont les systèmes de type Intel N-series / U-series et des pièces similaires basse consommation. Ils sont bons au repos, corrects en charge modérée et excellents pour les services réseau, la virtualisation légère et les workloads edge. L’astuce : assurer que la performance soutenue en charge est acceptable pour votre cas d’usage. Pour “toujours allumé, occasionnellement occupé”, c’est un bon compromis.
2) x86 embarqué (volontairement ennuyeux)
Les gammes embarquées sacrifient la performance de pointe pour la disponibilité à long terme et des enveloppes de puissance stables. Elles sont populaires dans les PC industriels, les appliances réseau et l’edge compute. Si votre achat doit rester identique pendant cinq ans, l’embarqué est votre ami.
3) SBC et modules ARM (le choix fanless par défaut)
Les cartes ARM sont souvent vendues sans ventilateur par conception. Elles peuvent être excellentes pour des workloads spécifiques (DNS, MQTT, petits caches, ingestion de capteurs, kiosques). Le mode de défaillance n’est généralement pas le CPU ; c’est le stockage (les cartes SD sont un péché de fiabilité sauf si traitées comme jetables) et la qualité de l’alimentation.
4) stations de travail passives spécialisées (oui, ça existe)
Refroidir passivement des postes de travail haute performance est possible avec d’énormes dissipateurs et un flux d’air de boîtier soigneusement conçu (ou, plus précisément, une convection du boîtier). Pour les systèmes de production, c’est de niche. Pour des studios silencieux et des labos, c’est réel. Ne prétendez juste pas que c’est un serveur en rack.
Blague n°1 : Un PC sans ventilateur est la seule machine qui peut planter en silence et rester hautain à ce sujet.
Où le calcul passif l’emporte en production
Edge et succursales : moins de pièces mobiles, moins de tickets
Les nœuds passifs brillent là où vous ne pouvez pas chaperonner le matériel. Points de vente, sites distants, usines, emplacements éphémères et “le placard qui stocke aussi des pots de peinture.” Les ventilateurs détestent la poussière, les peluches, les cheveux, la fumée et le temps. Les boîtiers passifs ne les aiment pas non plus, mais il n’y a pas de rotor pour se gripper et aucun roulement pour s’user jusqu’à la panne.
Environnements sensibles au bruit
Bureaux, studios, espaces médicaux, labos : le bruit n’est pas qu’une nuisance ; c’est un facteur humain. Les systèmes sans ventilateur éliminent la variabilité acoustique qui fait penser aux gens que quelque chose ne va pas même quand c’est “OK”. Le silence réduit aussi la tentation de cacher les systèmes dans des lieux terribles (comme des tiroirs fermés) juste pour éviter le bruit.
Ingénierie de fiabilité : moins de pièces qui s’usent
En termes SRE, les ventilateurs sont des composants classiques d’“usure”. Ils ont des courbes de défaillance prévisibles. Les systèmes passifs retirent une grande source de panne mécanique. Ça ne les rend pas immortels. Ça déplace le risque vers la thermique, le firmware et l’environnement. C’est un meilleur risque, parce qu’il est plus observable et testable.
Puissance prévisible, dimensionnement UPS plus simple
Les systèmes passifs à faible consommation simplifient la planification UPS. Vous pouvez exécuter plus de services sur des unités UPS plus petites et tolérer des coupures plus longues pour la même capacité de batterie. L’entreprise apprécie car c’est rare qu’une amélioration d’infrastructure réduise aussi les coûts.
Où le passif échoue (de manière prévisible) et comment le repérer tôt
Calcul intensif soutenu
Si votre charge est de la compilation soutenue, du transcodage, du chiffrement à débit élevé, de l’inférence ML à fort cycle d’utilisation, ou “on exécute tout sur cette seule machine”, le passif n’est peut-être pas l’outil adapté. Vous pouvez faire des rafales. Vous pouvez faire de la charge modérée soutenue. Mais si vous avez besoin d’horloges hautes en permanence, un châssis sans ventilateur devient une machine qui throttle. Le throttling n’est pas une panne ; c’est le système qui survit à votre plan.
Salles chaudes et armoires scellées
Fanless ne signifie pas “placer n’importe où.” Les systèmes passifs ont besoin d’échange d’air. Une armoire scellée transforme la convection naturelle en déception naturelle. Si vous ne pouvez pas améliorer la ventilation, vous devez réduire la puissance ou changer le matériel. Aucun optimisme n’abaissera la température ambiante.
Stockage et réseau haut débit sans considération thermique
Les lecteurs NVMe et les cartes 10GbE peuvent chauffer. Dans des boîtiers fanless, ils manquent souvent de flux d’air et comptent sur de petits pads thermiques. Le système peut garder le CPU heureux tandis que le SSD throttle, transformant votre nœud “rapide” en générateur de latence. Surveillez les thermiques du stockage et des NIC, pas seulement la température CPU.
Firmware qui ment, ou firmware qui panique
Certains mini PC sont livrés avec un comportement turbo agressif et une gestion thermique faible. D’autres ont des limites conservatrices qui brident les performances. Les déploiements passifs ont besoin d’un firmware qui se comporte de manière prévisible sous charge, expose les capteurs et supporte des plafonnages de puissance raisonnables.
Faits intéressants et contexte historique (court, concret)
- Les premiers ordinateurs domestiques fonctionnaient souvent sans ventilateur parce qu’ils utilisaient des CPU à un chiffre de watts et comptaient sur la convection ; le bruit n’était pas encore une contrainte de conception.
- Les ordinateurs portables ont poussé d’importantes avancées dans la coupure d’alimentation et le scaling dynamique des fréquences parce que l’autonomie a forcé le sujet bien avant les centres de données.
- Le basculement d’Intel vers des fenêtres turbo gérées agressivement a rendu les “courtes rafales rapides” courantes, ce qui est joli dans les benchmarks et délicat dans les boîtiers passifs.
- Les caloducs, jadis exotiques, sont devenus des pièces de commodité ; les châssis passifs modernes les utilisent souvent pour déplacer la chaleur vers de grands empilements d’ailettes éloignés du CPU.
- Les armoires télécom et contrôle industriel ont normalisé le refroidissement par conduction : le boîtier devient un répartiteur de chaleur, pas juste une boîte.
- Le throttling thermique des SSD est devenu visible quand le NVMe est passé de “stockage rapide” à “petit fourneau”, surtout dans les systèmes compacts.
- Les pannes de ventilateurs ne sont pas aléatoires ; elles corrèlent avec la poussière, l’orientation et le temps de service, d’où l’attrait du fanless pour les déploiements non surveillés.
- Les SoC modernes intègrent davantage de composants (contrôleurs mémoire, IO, parfois GPU), ce qui concentre la chaleur mais réduit aussi la puissance des chipsets externes.
Trois mini-histoires d’entreprises depuis le terrain
Mini-histoire 1 : L’incident causé par une mauvaise hypothèse (l’ambiante est “température de bureau”)
Une entreprise de taille moyenne a déployé des boîtiers edge sans ventilateur dans des dizaines de sites pour exécuter des caches d’authentification locaux et un broker de messages léger. Les tests en labo semblaient propres. Les boîtiers tournaient à 60–70°C en charge et ne throttlaient jamais. Les achats ont adoré l’argument “pas de pièces mobiles” et le déploiement a filé.
Puis l’été est arrivé. Une partie des sites a commencé à signaler des connexions lentes et des timeouts intermittents. L’équipe SRE centrale ne voyait rien d’alarmant dans l’utilisation CPU ; elle était modérée. Le réseau semblait ok. Ils ont redémarré des services, blâmé “problème ISP” et sont passés à autre chose. Les tickets sont revenus.
L’indice réel est venu d’une personne sur site qui a mentionné en passant que “l’armoire réseau est chaude.” Pas brûlante — tiède. Elle partageait l’espace avec une UPS et un switch PoE. L’armoire n’avait pas de ventilation active. L’ambiante intérieure tournait bien au-dessus de la température bureau, et les systèmes passifs vivaient à la limite de leur enveloppe thermique.
Dans ces conditions, le CPU n’a pas planté ; il a throttlé. Les opérations sensibles à la latence (handshakes TLS, petites écritures d’état local) sont devenues jittery. Les systèmes étaient toujours “up”, ce qui a rendu l’incident plus difficile : pas d’événement down évident, juste une dégradation.
La correction n’a pas été héroïque. Ils ont ajouté une ventilation d’armoire peu coûteuse aux pires emplacements, ont déplacé les boîtiers hors du chemin d’échappement de l’UPS, et ont imposé une règle de déploiement : mesurer l’ambiante de l’armoire pendant la journée, pas au moment de l’installation le matin. L’hypothèse erronée était de traiter l’ambiante comme une constante. Ce n’était pas le cas. Ça ne l’est jamais.
Mini-histoire 2 : L’optimisation qui s’est retournée contre eux (limites de puissance “pour l’efficacité”)
Une autre organisation voulait standardiser sur une plateforme mini PC fanless pour des runners CI dev/test. L’argument était simple : faible consommation, silencieux, haute densité sur étagères, moins de pannes. Quelqu’un a eu l’idée intelligente de brider la puissance CPU de manière agressive pour réduire la chaleur et améliorer la stabilité. Ça a marché — en partie.
Les runners sont devenus stables sous des tests de stress synthétiques. Les températures restaient basses et tout le monde a cessé de s’inquiéter du throttling. Ils ont déployé la configuration à grande échelle et ont déclaré victoire. Deux semaines plus tard, les développeurs ont commencé à se plaindre que les builds “prenaient aléatoirement plus de temps”, surtout quand la suite de tests tournait en parallèle.
La limitation avait changé le profil de performance : elle réduisait le débit de pointe et, plus important, rendait les machines plus lentes pour gérer des charges parallèles en rafale. Les systèmes de build sont pleins de rafales — tempêtes de compilation, étapes de linkage, fan-out de tests. La limitation n’a pas seulement baissé la performance ; elle a augmenté le temps d’attente en file, ce qui a amplifié la latence globale.
L’équipe a partiellement annulé la limite et a plutôt ajusté les fenêtres de turbo pour permettre de courtes rafales tout en évitant une longue accumulation de chaleur. Ils ont aussi séparé “builds interactifs dev” et “régressions batch” pour que les courses lourdes atterrissent sur moins de machines mieux refroidies. La leçon : optimiser pour l’efficacité n’est pas que des watts ; c’est la forme de la charge. Bridez la mauvaise chose et vous gagnez une machine plus lente, toujours chaude — mais plus longtemps.
Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (étalonnage des capteurs)
Une équipe de services financiers a déployé des appliances fanless pour la connectivité des succursales : VPN, règles de firewall et journalisation locale. Ils ont fait quelque chose d’anti-glamour : chaque unité a reçu une capture de base à l’installation. Températures CPU, températures SSD, stats NIC et compteurs de throttling. Stocké centralement.
Des mois plus tard, une succursale a signalé des coupures VPN intermittentes. L’appareil ne redémarrait pas. Les logs n’étaient pas utiles. Le fournisseur réseau a blâmé “alimentation locale”. L’équipe a comparé la télémétrie actuelle des capteurs à la baseline. Les températures CPU étaient plus élevées de 15°C au repos, et la température SSD frôlait sa limite. Ce delta racontait l’histoire.
Il s’est avéré que la succursale avait déplacé l’appliance dans un tiroir fermé pour “ranger les câbles”. L’équipe n’a pas eu besoin d’un déplacement sur site ; la signature thermique était évidente. Ils ont demandé à la succursale de la remettre à l’air libre, et le problème a disparu le jour même.
Une pratique ennuyeuse — étalonner vos capteurs — a évité des jours de discussions et un déplacement. L’ops n’est pas d’être malin. C’est d’avoir des preuves.
Tâches pratiques : commandes, sorties et décisions (12+)
Ce sont des contrôles pratiques que j’exécute réellement lors de la validation des déploiements fanless. Chaque tâche inclut : commande, sortie typique, ce que ça signifie et la décision à prendre.
1) Identifier le modèle CPU et les cœurs
cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|MHz'
Model name: Intel(R) Processor N100
CPU(s): 4
Thread(s) per core: 1
Core(s) per socket: 4
CPU MHz: 799.902
Signification : Confirme que vous êtes sur le silicium attendu et montre le comportement de fréquence au repos.
Décision : Si le modèle CPU diffère de la spécification (commun avec “même châssis, SKU différent”), arrêtez et réconciliez avant les tests de performance.
2) Confirmer que le noyau voit les zones thermiques
cr0x@server:~$ ls -1 /sys/class/thermal/
cooling_device0
cooling_device1
thermal_zone0
thermal_zone1
Signification : Les capteurs sont exposés.
Décision : Si les zones thermiques manquent, vous perdez l’observabilité ; mettez à jour le BIOS/firmware ou les modules du noyau avant de faire confiance à la plateforme.
3) Lire la température CPU actuelle depuis hwmon
cr0x@server:~$ for f in /sys/class/hwmon/hwmon*/temp1_input; do echo "$f: $(cat $f)"; done
/sys/class/hwmon/hwmon2/temp1_input: 52000
Signification : 52000 millidegrés C = 52°C.
Décision : Enregistrez valeurs au repos et en charge ; si l’idle est déjà élevé, l’emplacement ou l’accouplement du boîtier est suspect.
4) Vérifier si le CPU throttle (Intel)
cr0x@server:~$ sudo turbostat --Summary --quiet --show CPU,Busy%,Bzy_MHz,PkgWatt,PkgTmp,Throt
CPU Busy% Bzy_MHz PkgWatt PkgTmp Throt
- 12.35 2498 11.42 86 1
Signification : Throt=1 indique des événements de throttling thermique ou de puissance durant l’échantillon.
Décision : Si le throttling apparaît sous des workloads attendus, réduisez la charge soutenue, améliorez le chemin thermique du châssis, ou ajustez les limites de puissance.
5) Inspecter le gouverneur de fréquence du CPU
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
Signification : Le gouverneur affecte la réactivité et les pics de chaleur.
Décision : Pour des services sensibles à la latence, envisagez schedutil ou des profils tuned ; pour des appliances edge, powersave peut être correct.
6) Voir fréquence actuelle et limites
cr0x@server:~$ cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
hardware limits: 800 MHz - 3400 MHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 3400 MHz.
The governor "powersave" may decide which speed to use
current CPU frequency: 801 MHz
Signification : Établit les min/max attendus et le mode du driver.
Décision : Si la fréquence max est inférieure à l’attendu, le firmware peut brider. Décidez si ce bridage est intentionnel pour la stabilité passive.
7) Stress test CPU et surveiller les températures en temps réel
cr0x@server:~$ sudo apt-get -y install stress-ng >/dev/null
cr0x@server:~$ stress-ng --cpu 4 --cpu-method matrixprod --timeout 120s --metrics-brief
stress-ng: info: [2142] dispatching hogs: 4 cpu
stress-ng: metrc: [2142] cpu 120.00s 825.33 ops/s 99039.60 ops (mean)
stress-ng: info: [2142] successful run completed in 120.02s
Signification : Génère une charge de calcul soutenue.
Décision : Exécutez ceci en échantillonnant les températures / compteurs de throttling ; si la performance s’écroule à mi-parcours, vous êtes en heat-soak et throttling.
8) Vérifier dmesg pour les événements thermiques
cr0x@server:~$ dmesg -T | egrep -i 'thermal|throttl|critical|overheat' | tail -n 5
[Mon Jan 13 09:22:11 2026] CPU0: Core temperature above threshold, cpu clock throttled
[Mon Jan 13 09:22:11 2026] CPU0: Package temperature above threshold, cpu clock throttled
Signification : Le noyau vous dit qu’il a dû protéger le matériel.
Décision : Considérez cela comme une défaillance de conception, pas “normal”. Soit dégradez la charge, soit corrigez l’environnement thermique.
9) Vérifier la température NVMe et les avertissements de throttling
cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep 'temperature|warning|critical'
temperature : 67 C
warning_temp_time : 12
critical_comp_time : 0
Signification : Le SSD a passé du temps au-dessus de son seuil d’avertissement.
Décision : Si warning_temp_time augmente, ajoutez un dissipateur/pad thermique ou réduisez les charges d’écriture intensives sur ce nœud.
10) Mesurer la latence disque sous charge (sanity quick)
cr0x@server:~$ iostat -dx 1 3
Device r/s w/s r_await w_await aqu-sz %util
nvme0n1 0.00 45.00 0.00 2.10 0.09 12.0
nvme0n1 0.00 60.00 0.00 18.50 1.20 98.0
Signification : w_await a bondi et le %util est saturé — le stockage est saturé ou en throttling.
Décision : Si le CPU semble ok mais la latence IO spike, investiguez les thermiques NVMe et l’amplification d’écriture ; ne poursuivez pas des fantômes CPU.
11) Vérifier le lien NIC et les compteurs d’erreurs
cr0x@server:~$ ip -s link show dev enp2s0
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 58:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
92838333 99233 0 0 0 0
TX: bytes packets errors dropped carrier collsns
77228112 88321 0 0 0 0
Signification : Des compteurs propres suggèrent une bonne santé de lien.
Décision : Si des erreurs incrémentent pendant le heat soak, suspectez la thermique du NIC ou une alimentation marginale ; déplacez la boîte et retestez avant de remplacer le matériel.
12) Confirmer la consommation et les caps (Intel RAPL)
cr0x@server:~$ sudo apt-get -y install linux-tools-common linux-tools-$(uname -r) >/dev/null
cr0x@server:~$ sudo powertop --time=2 --html=/tmp/powertop.html >/dev/null
cr0x@server:~$ ls -lh /tmp/powertop.html
-rw-r--r-- 1 root root 188K Jan 13 09:30 /tmp/powertop.html
Signification : Vous avez maintenant un snapshot de base power/tuning.
Décision : Utilisez-le pour comparer “avant/après” lors de changements de gouverneur, limites de puissance ou placement de workload.
13) Vérifier le journal systemd pour instabilités style “brownout”
cr0x@server:~$ journalctl -k -b | egrep -i 'mce|edac|nvme.*reset|pcie.*error|timeout' | tail -n 8
Jan 13 09:18:04 server kernel: nvme nvme0: I/O 183 QID 4 timeout, aborting
Jan 13 09:18:05 server kernel: nvme nvme0: controller reset scheduled
Signification : Les erreurs de stockage peuvent ressembler à une “lenteur aléatoire” et peuvent corréler avec la chaleur.
Décision : Si cela apparaît pendant une charge soutenue, traitez le refroidissement NVMe et la stabilité d’alimentation (PSU/brick), pas seulement le refroidissement CPU.
14) Valider le throttling CPU des conteneurs (cgroups)
cr0x@server:~$ systemctl is-active docker
active
cr0x@server:~$ cat /sys/fs/cgroup/system.slice/docker.service/cpu.stat
usage_usec 91233421
user_usec 81100220
system_usec 10133201
nr_periods 1223
nr_throttled 98
throttled_usec 18333211
Signification : C’est du throttling cgroup (quota), pas du throttling thermique.
Décision : Si la latence du service corrèle avec nr_throttled, ajustez les quotas CPU des conteneurs avant de repenser le refroidissement.
15) Confirmer que ZFS (ou autre stockage) n’est pas le chauffeur caché
cr0x@server:~$ sudo zpool status
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
nvme0n1p2 ONLINE 0 0 0
errors: No known data errors
cr0x@server:~$ arc_summary | egrep 'ARC size|ARC hit ratio' | head -n 2
ARC size (current): 1.2 GiB
ARC hit ratio (overall): 92.4 %
Signification : Santé ZFS et comportement du cache.
Décision : Si l’ARC est trop grand pour la RAM ou si vous forcez des écritures constantes (workloads sync), vous pouvez chauffer le stockage ; ajustez la charge ou ajoutez de la RAM.
Playbook de diagnostic rapide : trouver le goulot vite
Quand un système sans ventilateur “semble lent”, vous devez séparer quatre coupables communs : throttling thermique, limites de puissance, throttling IO (surtout NVMe) et mise en file induite par la charge (cgroups, ordonnanceur, voisins bruyants). Voici un ordre pratique d’opérations.
Premier : vérifier le throttling thermique (CPU + SSD)
- Regardez les logs du noyau pour des événements de throttling thermique.
- Vérifiez la température CPU et les compteurs de throttling.
- Vérifiez la température NVMe et le temps d’avertissement.
Si vous voyez du throttling, arrêtez de débattre l’optimisation applicative. Vous manquez de budget thermique. Corrigez l’environnement ou dégradez la charge.
Second : vérifier la latence IO et les resets de stockage
iostat -dxpour await/util.journalctl -kpour timeouts/resets NVMe.
Les blocages IO peuvent ressembler à une lenteur CPU parce que tout attend le stockage. Dans les boîtiers fanless, les thermiques SSD sont souvent le vrai méchant portant le masque du CPU.
Troisième : vérifier la politique d’alimentation et les limites CPU
- Gouverneur et limites cpufreq.
- Caps de puissance définis par le firmware ou les outils OS.
Si la machine est artificiellement bridée, votre “problème thermique” peut être un choix de configuration. Décidez si vous voulez du débit ou du silence avec marge.
Quatrième : vérifier la mise en forme des workloads et le throttling cgroup
- Quotas CPU des conteneurs et stats de throttling.
- Moyennes de charge vs utilisation CPU réelle.
Si le système n’est pas chaud et que l’IO est correct, vous êtes probablement sursouscrit ou limité par quota. Corrigez l’ordonnancement. Ne redessinez pas le châssis.
Erreurs courantes : symptômes → cause racine → correction
1) Symptom : “C’est rapide pendant 2 minutes, puis ça devient lent”
Cause racine : Heat soak et throttling thermique après la fin de la fenêtre turbo.
Correction : Mesurez la performance soutenue avec un test de charge de 10–20 minutes ; limitez le turbo ou réduisez la charge soutenue ; améliorez le placement et la convection.
2) Symptom : “Les températures CPU ont l’air correctes, mais tout est lent”
Cause racine : Throttling thermique NVMe ou resets du contrôleur SSD.
Correction : Vérifiez nvme smart-log et les logs noyau ; ajoutez un dissipateur/pad thermique SSD ; déplacez les workloads à fortes écritures hors du nœud.
3) Symptom : “Pertes réseau aléatoires sous charge”
Cause racine : Chauffe NIC, alimentation marginale, ou erreurs PCIe sous stress température/puissance.
Correction : Vérifiez ip -s link et les logs PCIe du noyau ; améliorez le refroidissement autour de la NIC ; remplacez l’alimentation par une unité connue bonne.
4) Symptom : “Stable sur le banc, instable dans l’armoire”
Cause racine : Température ambiante et air piégé ; l’armoire devient un réservoir de chaleur.
Correction : Mesurez l’ambiante de l’armoire ; ajoutez ventilation ; évitez l’empilement ; montez avec dégagement autour des ailettes.
5) Symptom : “La performance est constamment inférieure à l’attendu, mais les températures sont basses”
Cause racine : Limites de puissance firmware conservatrices ou OS configuré pour économiser l’énergie.
Correction : Validez les limites cpufreq ; ajustez le gouverneur/profil tuned ; envisagez d’augmenter PL1 modestement tout en vérifiant les températures soutenues.
6) Symptom : “Pics de latence seulement pendant les sauvegardes ou scrubs”
Cause racine : Jobs intensifs en stockage saturent l’IO et réchauffent les SSD dans un boîtier sans ventilateur.
Correction : Planifiez les tâches IO lourdes dans des périodes plus fraîches ; limitez le débit ; assurez le refroidissement SSD ; envisagez de séparer les rôles (nœud de backup vs nœud de service).
7) Symptom : “Il chauffe même au repos”
Cause racine : Interface thermique mauvaise, ailettes bloquées, orientation de montage incorrecte, ou processus en arrière-plan empêchant les états C profonds.
Correction : Vérifiez les C-states avec powertop ; inspectez le montage physique et le dégagement des ailettes ; réduisez le churn en arrière-plan (logs, scans, télémétrie agressive).
Blague n°2 : Le moyen le plus rapide de refroidir une boîte sans ventilateur est d’arrêter la charge que vous aviez promis d’être “légère.”
Listes de vérification / plan pas à pas pour déployer du fanless
Étape 1 : Décidez si la forme de charge convient au passif
- Bonnes correspondances : DNS/DHCP, petits services web, cache local, points VPN, métriques/télémétrie, nœuds Kubernetes edge légers, stockage home lab avec IO modéré.
- Mauvaises correspondances : transcodage vidéo soutenu, compilation constante, fortes écritures DB sur un NVMe seul sans flux d’air, routage 10GbE à fort cycle sans design thermique.
Si votre cycle d’utilisation est “toujours chaud”, achetez du refroidissement actif et passez à autre chose.
Étape 2 : Validez les thermiques soutenues dans votre pire ambiante
- Testez à une ambiante réaliste (ou simulez avec une pièce/armoire chauffée).
- Exécutez 20–30 minutes de charge mixte CPU+IO, pas seulement un benchmark de 2 minutes.
- Enregistrez températures et compteurs de throttling comme baseline.
Étape 3 : Traitez le refroidissement SSD et NIC comme priorités
- Utilisez des NVMe avec caractéristiques thermiques raisonnables et bonne télémétrie SMART.
- Assurez-vous que les pads thermiques touchent réellement la plaque du châssis ; “pad près du disque” n’est pas conduction.
- Privilégiez des NIC connues pour bien se comporter sans flux d’air si le boîtier est compact.
Étape 4 : Définissez une politique explicite de puissance et performance
- Choisissez intentionnellement un gouverneur/profil tuned.
- Documentez les réglages BIOS (turbo, limites de puissance) par modèle matériel.
- Décidez si vous optimisez pour la latence, le débit ou la marge thermique. Vous n’obtenez pas les trois gratuitement.
Étape 5 : Déployez avec une observabilité adaptée au risque
- Exportez température CPU, température SSD, compteurs de throttling et moyennes de charge.
- Alertez sur les écarts par rapport à la baseline (alertes delta détectent les événements “mis dans un tiroir”).
- Conservez une photo “install ok” pour les sites distants : orientation et dégagement comptent.
Étape 6 : Discipline opérationnelle
- Planifiez les maintenances IO lourdes pendant les périodes plus fraîches.
- Ne pas empiler des boîtes passives sans espacement.
- Utilisez des alimentations de qualité ; les brownouts et blocs bon marché causent des pannes “mystérieuses” qui ressemblent à des bugs logiciels.
FAQ
1) Les CPU fanless sont-ils vraiment fiables, ou c’est juste un hobby du silence ?
Ils peuvent être très fiables quand le budget thermique est respecté. Vous supprimez un mode de panne mécanique courant (les ventilateurs) et le remplacez par une exigence de gestion thermique. La fiabilité s’améliore quand vous pouvez contrôler l’ambiante et la charge.
2) Le refroidissement passif signifie-t-il toujours throttling ?
Non. Cela signifie une dissipation de puissance soutenue limitée. Un système passif bien conçu peut fonctionner indéfiniment dans son enveloppe prévue sans throttling. Le problème vient des gens qui achètent une boîte passive et y exécutent une charge prévue pour un refroidissement actif.
3) Quelle température est “trop chaude” pour un CPU sans ventilateur ?
Ça dépend du CPU, mais comme règle d’ops : si vous voyez des messages répétés de throttling thermique du noyau ou des températures de jonction proches du maximum en charge normale, vous êtes hors marge. Traitez les événements de throttling comme actionnables, pas cosmétiques.
4) Pourquoi les SSD comptent-ils autant dans les designs fanless ?
Les NVMe peuvent throttler sévèrement et silencieusement. Ils se trouvent aussi souvent à des emplacements thermiques gênants. Dans un boîtier passif compact, le SSD devient souvent le facteur limitant de performance et de stabilité, pas le CPU.
5) Puis-je exécuter ZFS sur un serveur domestique fanless ?
Oui, si vous dimensionnez la RAM correctement et évitez de transformer le système en four d’écriture constant. Surveillez les températures NVMe pendant les scrubs et sauvegardes. Planifiez les jobs lourds et surveillez la latence ; le passif ne pardonne pas la saturation “toujours active”.
6) Quel est le meilleur emplacement pour une boîte passive ?
Verticale ou avec les ailettes orientées pour favoriser la convection (dépend du design du châssis), avec dégagement autour des surfaces du dissipateur. Pas dans des armoires scellées. Pas empilée serrée. Si vous ne sentez pas un léger flux d’air chaud au-dessus après un moment, la convection est probablement entravée.
7) Ai-je besoin de réglages BIOS spéciaux pour l’opération fanless ?
Souvent, oui. Certains systèmes sortent avec des defaults turbo agressifs. Pour le passif, vous voulez généralement une puissance soutenue prévisible : ajustez PL1/PL2 (si disponibles), limitez la durée turbo et assurez-vous que les capteurs sont correctement exposés à l’OS.
8) Les systèmes ARM fanless sont-ils “plus faciles” que x86 fanless ?
Thermiquement, parfois — les SoC ARM peuvent être très efficaces. Opérationnellement, les risques plus importants sont le média de stockage (évitez les cartes SD pour des charges d’écriture sérieuses) et la qualité d’alimentation. Vérifiez aussi la maturité des drivers pour votre NIC/stockage.
9) Quelle est la façon la plus simple de dire si ma lenteur est thermique ou logicielle ?
Cherchez des indicateurs de throttling et corrélez la latence avec la température dans le temps. Si la performance baisse après une charge soutenue et récupère après refroidissement, c’est thermique. Si ça corrèle avec la profondeur de file, l’attente IO ou le throttling cgroup, c’est logiciel/config.
10) Quand dois-je éviter le fanless et acheter du matériel à refroidissement actif ?
Quand la charge est soutenue et lourde en calcul ou IO, ou quand l’ambiante est incontrôlée et chaude. Si l’environnement est hostile et que vous ne pouvez pas ventiler, le passif peut être pire car il throttlera plutôt que de forcer avec du flux d’air.
Prochaines étapes réalisables cette semaine
Si vous envisagez le calcul passif, ne commencez pas par un panier d’achats. Commencez par un budget thermique et un profil de workload.
- Choisissez un workload candidat (passerelle edge, petit cache, nœud de monitoring) et définissez son cycle d’utilisation soutenu.
- Exécutez un test de charge mixte de 30 minutes sur le matériel cible tout en collectant température CPU, température NVMe et compteurs de throttling.
- Établissez la baseline de l’environnement : mesurez l’ambiante d’armoire/pièce à la partie la plus chaude de la journée.
- Décidez votre politique : préférez-vous débit stable (caps de puissance) ou rafales à faible latence (turbo contrôlé) ? Documentez-la.
- Rendez l’observabilité obligatoire : exportez les métriques de capteurs et alertez sur les écarts par rapport à la baseline, pas seulement sur des valeurs absolues.
Le fanless n’est pas magique. C’est un compromis que vous pouvez gagner, tant que vous traitez la thermique comme un SLO : mesurable, applicable et jamais supposée.