Puedes gastar seis cifras en cómputo, ajustar tu kernel, dimensionar tus capas de almacenamiento y aun así perder un nodo por un problema
que cuesta exactamente $0 crear: una pequeña lámina de plástico adhesiva dejada sobre la placa fría del disipador.
El modo de fallo es mitad slapstick, mitad brutal: la máquina arranca, funciona “bien”, y luego empieza a bajar rendimiento por throttling, emitir
alarmas térmicas, reducir el rendimiento de NVMe o reiniciarse bajo carga. El panel de control grita. Tu pager grita más fuerte.
Por qué una pegatina en el disipador puede tumbar producción
La “pegatina del disipador” suele ser una lámina protectora transparente en la placa fría de un disipador de CPU (de aire o AIO). Está ahí para
mantener el metal limpio y sin arañazos en el almacén. No está ahí para ser una interfaz térmica. De hecho, es una
forma casi perfecta de convertir tu costosa solución de refrigeración en un experimento de retención de calor.
La transferencia de calor desde la CPU al disipador es una cadena. Rompe un eslabón, el resto no importa:
- Die → IHS (ruta interna del paquete CPU, fuera de tu control).
- IHS → pasta térmica (tu control; fina, uniforme, no artística).
- Pasta térmica → placa fría (tu control; contacto metálico limpio).
- Placa fría → heatpipes/radiador (diseño del disipador).
- Radiador/aletas → flujo de aire (caja o chasis, curvas de ventiladores, obstrucciones).
Una pegatina se interpone justo en la interfaz más importante: el contacto con la placa fría. Incluso si la pegatina es
“delgada”, introduce una capa con mala conductividad térmica y a menudo atrapa microespacios llenos de aire. La pasta
térmica no lo arregla; la pasta sobre plástico es solo pasta con un pasatiempo.
En una estación de trabajo, esto se convierte en “mi juego se entrecorta”. En un servidor, se vuelve “mi nodo desaparece
intermitentemente” o “latencias que suben en picos bajo tráfico pico”, o peor: “las reconstrucciones de almacenamiento
tardan una eternidad y luego la caja se reinicia.”
Una verdad seca: el sobrecalentamiento rara vez es una falla limpia. Es desordenado. Se disfraza de RAM inestable, firmware
defectuoso, vecinos ruidosos, saturación de almacenamiento o “Kubernetes siendo Kubernetes.”
Chiste #1 (corto, relevante): La pegatina del disipador es la única película protectora que bloquea con éxito el calor en lugar de a los hackers.
Guion de diagnóstico rápido (primero/segundo/tercero)
No obtienes puntos por “análisis profundo” mientras la flota se cocina. Obtienes puntos por restaurar el servicio y prevenir
incidentes repetidos. Aquí hay un orden de triaje rápido que encuentra el cuello de botella pronto, con mínima fricción.
Primero: confirma que es térmico, no “simplemente lento”
- Busca throttling: la frecuencia de la CPU baja bajo carga, a pesar de alta utilización.
- Revisa temperaturas: temperatura del paquete CPU cerca o en TjMax; temperaturas de GPU/NVMe altas si procede.
- Busca eventos térmicos: logs del kernel, SEL de IPMI, alarmas de sensores BMC.
Segundo: determina alcance y radio de impacto
- ¿Nodo único o muchos? Si son muchos, sospecha flujo de aire ambiente, política de control de ventiladores, despliegue de firmware o filtros obstruidos.
- ¿Es específico de la carga? ¿Solo bajo AVX intenso, compactación sostenida, reconstrucción o cifrado?
- ¿Correlación temporal? Lo mismo a la misma hora cada día puede ser trabajos por lotes, pero también puede ser horarios de manejo de aire o hábitos de puertas de rack.
Tercero: decide la vía de mitigación más segura
- Seguridad inmediata: reduce la carga, drena cargas, limita potencia, incrementa la política de velocidad de ventiladores.
- Revisión física: si es una nueva construcción o una unidad recientemente atendida, asume error de instalación hasta que se demuestre lo contrario.
- Solución permanente: limpiar/reemplazar ventiladores, volver a montar el disipador, quitar la pegatina, reaplicar pasta, actualizar firmware, ajustar diseño de flujo de aire.
El camino más rápido para saber “¿es la pegatina?” es brutalmente simple: si esto es una nueva construcción, un intercambio de disipador o un reseat de CPU,
y ves sobrecalentamiento inmediato incluso con carga moderada, trata la interfaz de la placa fría como culpable hasta que se demuestre inocente.
Datos interesantes y un poco de historia
El sobrecalentamiento es antiguo. El incidente de la pegatina es más nuevo de lo que la mayoría piensa, y es más común ahora porque el bricolaje y
el despliegue rápido han cambiado la ergonomía del trabajo con hardware. Unos puntos concretos para fundamentar la historia:
- El throttling térmico no es una invención moderna. Las CPUs han tenido formas de protección térmica durante décadas; los chips modernos solo lo hacen más dinámico y difícil de notar.
- Las películas protectoras se volvieron más comunes a medida que los disipadores se volvieron premium. Las placas frías con acabado espejo y la pasta preaplicada se envían con películas para evitar contaminación y arañazos.
- La pasta no es pegamento. Su trabajo es rellenar vacíos microscópicos; el contacto metal a metal sigue siendo la principal vía de calor.
- El control de ventiladores cambió de voltaje “tonto” a curvas inteligentes. El control PWM y las políticas BMC pueden enmascarar un mal contacto “salvándote” en reposo y fallando a carga sostenida.
- Los centros de datos cada vez operan con temperaturas de admisión más altas. Los objetivos de eficiencia impulsan pasillos más cálidos; el margen para “pequeños” errores se reduce.
- NVMe trajo nuevos cuellos de botella térmicos. Los SSD modernos reducen rendimiento por temperatura y pueden parecer “latencia de almacenamiento” en lugar de “calor”.
- AVX y conjuntos de instrucciones similares pueden cambiar el perfil térmico. La misma CPU con la misma utilización puede calentarse drásticamente según la mezcla de instrucciones.
- La gestión remota normalizó las operaciones “sin manos”. Las herramientas IPMI/BMC facilitaron olvidar que algunas fallas requieren ojos y un destornillador.
- Los pads térmicos en VRM y memoria existen por una razón. Un desalineamiento durante el montaje puede sobrecalentar la entrega de energía mientras la CPU parece bien, produciendo reinicios extraños y errores WHEA.
Cómo se ve en logs, métricas e informes de usuarios
El error de la pegatina tiene una firma: las temperaturas se disparan rápido y pronto. No “después de una hora”, sino “en minutos de
cualquier carga real.” La curva de ventiladores llega al máximo. La CPU aún se sobrecalienta. Esa discordancia—ventiladores chillando y temperaturas aún subiendo—es la pista.
Síntomas superficiales comunes
- Reinicios aleatorios bajo carga (apagado térmico o protección de VRM).
- Picos repentinos de latencia (la CPU reduce frecuencia; las colas crecen).
- Resultados de benchmark inconsistentes (el equilibrio térmico cambia entre ejecuciones).
- “El almacenamiento se volvió lento” (NVMe reduce rendimiento por temperatura; la latencia de IO se vuelve errática y las compactaciones/reconstrucciones se alargan).
- Frecuencia de CPU atascada baja a pesar de tener margen en papel.
- Mensajes del kernel sobre zonas térmicas o pistas de “CPU throttled”.
- Alarmas de sensores IPMI (CPU Temp, VRM Temp, System Temp) o eventos SEL.
Qué está pasando realmente
Cuando la CPU alcanza límites térmicos, no pide por favor. Cambia su comportamiento: baja frecuencia y voltaje,
recorta turbo, a veces fuerza límites de potencia, y si las temperaturas siguen subiendo, activa un apagado protector.
Estos controles preservan la vida del silicio. No preservan tu SLO.
En producción, el throttling es especialmente desagradable porque es no lineal. Puedes estar bien al 55% de carga, luego
golpear una rodilla y caer de un acantilado al 70%. Tu planificación de capacidad parece correcta hasta que deja de serlo.
Tareas prácticas: comandos, salidas, decisiones (12+)
Estas son las comprobaciones que realmente ejecuto. Cada tarea incluye: un comando, una salida representativa, lo que significa y la
decisión que tomas. Puedes hacer la mayoría sin apagar la caja—hasta el momento en que debes hacerlo.
Tarea 1: Comprobar frecuencias actuales de CPU (pista de throttling)
cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|MHz'
Model name: Intel(R) Xeon(R) CPU
CPU(s): 32
Thread(s) per core: 2
CPU MHz: 1197.843
Significado: Una CPU de servidor inactiva alrededor de 1200 MHz es normal en reposo, sospechosa bajo carga.
Decisión: Si los usuarios reportan lentitud y esto se mantiene bajo durante la carga, sigue buscando throttling.
Tarea 2: Vigilar la frecuencia bajo carga en tiempo real
cr0x@server:~$ sudo apt-get -y install linux-tools-common linux-tools-generic >/dev/null
cr0x@server:~$ sudo turbostat --Summary --interval 2
turbostat version 2024.01
Summary: 2 sec
Avg_MHz Busy% Bzy_MHz TSC_MHz PkgTmp PkgWatt
1680 92.15 1822 2300 97 182.4
Significado: Temperatura del paquete 97°C con núcleos ocupados y Bzy_MHz menor de lo esperado indica límite térmico.
Decisión: Confirma temperaturas vía sensors/IPMI y planifica mitigación inmediata (drenar/reducir carga).
Tarea 3: Leer sensores térmicos localmente (lm-sensors)
cr0x@server:~$ sudo apt-get -y install lm-sensors >/dev/null
cr0x@server:~$ sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +98.0°C (high = +84.0°C, crit = +100.0°C)
Core 0: +96.0°C (high = +84.0°C, crit = +100.0°C)
Core 1: +97.0°C (high = +84.0°C, crit = +100.0°C)
Significado: Estás rozando el crítico. Que el valor “High” esté superado significa que es probable un throttling sostenido.
Decisión: Si este es un sistema nuevo/serviciado, prioriza la inspección física (montaje/pasta/pegatina).
Tarea 4: Revisar el kernel por eventos térmicos
cr0x@server:~$ sudo dmesg -T | egrep -i 'thermal|thrott|critical|overheat' | tail -n 8
[Mon Jan 22 10:41:12 2026] CPU0: Package temperature above threshold, cpu clock throttled
[Mon Jan 22 10:41:12 2026] CPU2: Package temperature above threshold, cpu clock throttled
[Mon Jan 22 10:41:15 2026] CPU0: Core temperature/speed normal
Significado: El kernel te está diciendo que hizo throttling. Esto no es “quizás.”
Decisión: Trátalo como causa del incidente, no como una línea incidental del log; ajusta la capacidad y arregla la refrigeración.
Tarea 5: Confirmar RPM de ventiladores y temperaturas del sistema vía IPMI
cr0x@server:~$ sudo apt-get -y install ipmitool >/dev/null
cr0x@server:~$ sudo ipmitool sdr type Temperature
CPU Temp | 98 degrees C | critical
System Temp | 36 degrees C | ok
VRM Temp | 92 degrees C | non-critical
Significado: La temperatura de admisión/sistema está bien; CPU/VRM están calientes. Eso apunta lejos de “la sala está caliente” y hacia “contacto/flujo interno.”
Decisión: Si los ventiladores ya están altos, sospecha disipador bloqueado, mal montaje, pegatina o bomba muerta (AIO).
Tarea 6: Comprobar sensores de ventiladores vía IPMI
cr0x@server:~$ sudo ipmitool sdr type Fan
FAN1 | 17600 RPM | ok
FAN2 | 17400 RPM | ok
FAN3 | 17100 RPM | ok
FAN4 | 0 RPM | critical
Significado: Un ventilador está muerto o desenchufado. En algunos chasis, un ventilador faltante arruina el patrón de presión.
Decisión: Reemplaza/ajusta el ventilador primero. Si todos los ventiladores están OK y las temperaturas aún suben, pasa a la interfaz de placa fría.
Tarea 7: Leer el System Event Log de IPMI para razones de apagado
cr0x@server:~$ sudo ipmitool sel elist | tail -n 6
1a2 | 01/22/2026 | 10:42:01 | Temperature CPU Temp | Upper Critical going high
1a3 | 01/22/2026 | 10:42:05 | Processor #0 | Thermal Trip
1a4 | 01/22/2026 | 10:42:06 | System Boot Initiated | Initiated by power reset
Significado: Un trip térmico precedió al reinicio. El BMC lo vio.
Decisión: Deja de culpar al hipervisor. Arregla la refrigeración. Conserva los logs para el postmortem.
Tarea 8: Verificar consumo y comportamiento de límites de potencia (RAPL / turbostat)
cr0x@server:~$ sudo turbostat --Summary --interval 2 | head -n 4
turbostat version 2024.01
Summary: 2 sec
Avg_MHz Busy% Bzy_MHz PkgTmp PkgWatt
1450 88.40 1601 99 205.7
Significado: Alta potencia a alta temperatura, y aun así MHz mediocre: la refrigeración no puede evacuar el calor.
Decisión: A corto plazo: aplica un tope de potencia para reducir la escalada térmica mientras agendas reparación manual.
Tarea 9: Aplicar un tope temporal de potencia de CPU (mitigación segura)
cr0x@server:~$ sudo apt-get -y install linux-tools-common linux-tools-generic >/dev/null
cr0x@server:~$ sudo powercap-info -p intel-rapl:0
Zone intel-rapl:0
enabled: 1
constraint_0_power_limit_uw: 220000000
constraint_1_power_limit_uw: 250000000
cr0x@server:~$ echo 160000000 | sudo tee /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
160000000
Significado: Has reducido el límite de potencia sostenida del paquete a 160W.
Decisión: Úsalo para mantener el sistema vivo el tiempo suficiente para drenar cargas. No llames a esto “arreglado.”
Tarea 10: Hacer un test de estrés breve para reproducir sin freírlo
cr0x@server:~$ sudo apt-get -y install stress-ng >/dev/null
cr0x@server:~$ sudo stress-ng --cpu 0 --cpu-method matrixprod --timeout 30s --metrics-brief
stress-ng: info: [21432] dispatching hogs: 32 cpu
stress-ng: info: [21432] successful run completed in 30.01s
stress-ng: info: [21432] cpu: 960.00 bogo ops/s
Significado: Has creado una carga térmica reproducible. Empareja esto con sensors/turbostat para ver la tasa de subida de temperatura.
Decisión: Si las temperaturas suben a altos 90s en segundos y los ventiladores están al máximo, detén y revisa montaje/pegatina/bomba.
Tarea 11: Comprobar throttling térmico de NVMe (“lentitud” misteriosa de almacenamiento)
cr0x@server:~$ sudo apt-get -y install nvme-cli >/dev/null
cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep 'temperature|warning|critical'
temperature : 78 C
warning_temp_time : 134
critical_comp_time : 0
Significado: NVMe está caliente y ha pasado tiempo por encima de su umbral de advertencia. Puede que ya esté reduciendo rendimiento.
Decisión: Añade flujo de aire sobre NVMe, verifica disipadores y deja de asumir que el disco está “lento.” Puede que esté “caliente.”
Tarea 12: Comprobar errores corregibles PCIe (el calor puede desestabilizar enlaces)
cr0x@server:~$ sudo dmesg -T | egrep -i 'aer|pcie|corrected|whea' | tail -n 6
[Mon Jan 22 10:39:44 2026] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
[Mon Jan 22 10:39:44 2026] pcieport 0000:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer
Significado: No es concluyente, pero un aumento de errores corregidos bajo calor/carga puede indicar integridad de señal marginal o estrés térmico.
Decisión: Si los errores se correlacionan con altas temperaturas, arregla la refrigeración antes de reemplazar hardware.
Tarea 13: Verificar modo/política de ventiladores del BMC (una mala configuración puede aparentar fallo de hardware)
cr0x@server:~$ sudo ipmitool raw 0x30 0x45 0x00
01
Significado: Específico del proveedor, pero a menudo devuelve el modo actual de ventilador (p. ej., “standard” vs “full”).
Decisión: Si la política es demasiado silenciosa para tu perfil térmico, cámbiala temporalmente a un modo más alto; luego revisa el flujo de aire adecuadamente.
Tarea 14: Comprobar síntomas de orquestación de contenedores (los nodos que hacen flap parecen software)
cr0x@server:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
worker-07 NotReady <none> 18d v1.29.2
worker-08 Ready <none> 18d v1.29.2
cr0x@server:~$ kubectl describe node worker-07 | egrep -i 'Ready|KubeletNotReady|reboot|pressure' | tail -n 8
Ready False Mon, 22 Jan 2026 10:42:15 +0000 KubeletNotReady runtime network not ready
Ready True Mon, 22 Jan 2026 10:30:02 +0000 KubeletReady kubelet is posting ready status
Significado: Flapping de nodo. “Runtime network not ready” puede ser un efecto secundario de reinicios abruptos.
Decisión: Revisa SEL del BMC y temperaturas antes de perseguir fantasmas de CNI durante tres horas.
Tarea 15: Confirmar mantenimiento reciente (los incidentes de pegatina se correlacionan con “tocamos esto”)
cr0x@server:~$ last -x | head -n 8
reboot system boot 6.8.0-40-generic Mon Jan 22 10:42 still running
shutdown system down 6.8.0-40-generic Mon Jan 22 10:41 - 10:42 (00:00)
reboot system boot 6.8.0-40-generic Mon Jan 22 10:12 - 10:41 (00:29)
Significado: Reboots múltiples en una ventana corta: o pruebas, inestabilidad o bucles de apagado térmico.
Decisión: Cruza con tickets de cambio. Si un disipador/CPU fue reubicado recientemente, prioriza la inspección física.
Tarea 16: Si debes abrir la caja, documenta y verifica el patrón de contacto
cr0x@server:~$ sudo mkdir -p /var/tmp/thermal-incident && sudo date | sudo tee /var/tmp/thermal-incident/notes.txt
Mon Jan 22 10:55:03 UTC 2026
Significado: Estás creando una carpeta de artefactos del incidente antes de manipular componentes.
Decisión: Toma fotos de la placa fría, presencia de pegatina y extensión de la pasta. Esto es oro para postmortems y formación.
Chiste #2 (corto, relevante): Si tu CPU llega a 100°C con ventiladores al máximo, no es “modo turbo”—es “por favor, quita el plástico.”
Tres micro-historias corporativas desde las trincheras del sobrecalentamiento
Micro-historia 1: El incidente causado por una suposición errónea
Una compañía mediana desplegó un nuevo lote de nodos de cómputo para CI y entornos efímeros. El hardware llegó
pre-rackeado por un proveedor, se imagenó internamente y luego se unió a un clúster. Durante dos días, todo parecía estar bien—porque las
cargas eran espasmódicas y cortas.
En el tercer día, activaron una nueva suite de pruebas que ejecutaba compilaciones sostenidas y pesadas de CPU. De repente, los trabajos empezaron a agotar
tiempo. Los ingenieros lo vieron como “contención de colas” y ampliaron el grupo de runners. Eso lo empeoró: más nodos entraron en carga sostenida,
más fallos se acumularon y el scheduler parecía embrujado.
La suposición errónea fue sutil: “Si arranca y pasa una prueba de humo de 10 minutos, los térmicos están bien.” No lo estaban.
La prueba de humo nunca llegó al estado estable. Bajo carga sostenida, las CPUs alcanzaron umbrales térmicos, limitaron frecuencia
y luego hicieron trip. Algunos nodos se recuperaron; otros cayeron en bucles de reinicio que parecían problemas de aprovisionamiento.
La pista eventual vino de una sola persona que dejó de leer logs de software y sacó datos IPMI. Eventos críticos de temperatura de CPU se alineaban con timeouts de trabajos. Un técnico abrió un chasis. La placa fría aún tenía la película protectora puesta.
Una vez encontraron uno, encontraron varios. Error en la línea de montaje por lote, no un fallo aislado. La parte “divertida” duró
unos diez segundos; el resto fue recalcular capacidad, reprocesar nodos y escribir una nueva prueba de aceptación que ejecutara una
carga sostenida real mientras registraba temperaturas.
Micro-historia 2: La optimización que salió mal
Otra organización buscó ahorrar energía. La factura del centro de datos mordía, y la dirección quería “victorias de eficiencia.”
Alguien propuso bajar las velocidades de los ventiladores cambiando el modo BMC de alto rendimiento a un perfil más silencioso y de menor RPM. El cambio se desplegó por automatización.
Al principio: éxito. Menos ruido en el laboratorio. Menor consumo en reposo. Luego llegó el mundo real. El ambiente veraniego subió, los racks se hicieron más densos, y algunos chasis mostraron un flujo de aire ligeramente imperfecto por montones de cables y huecos en paneles ciegos. Bajo carga pico, ciertos nodos empezaron a mostrar picos de latencia intermitentes. Nada dramático. Suficiente para ser caro.
La optimización salió mal porque estrechó el margen. Con menos margen en los ventiladores, cualquier resistencia térmica extra—polvo,
pasta envejecida, presión de disipador desajustada o sí, una pegatina olvidada tras un reemplazo de CPU—empujó el sistema por encima del límite. El mismo hardware que toleraba errores a “ventilador completo” no lo hacía en “modo eco.”
El equipo aprendió dos lecciones. Primero: la política de ventiladores es parte del presupuesto de fiabilidad, no solo de acústica. Segundo:
desplegar cambios de modo de ventilador sin caracterización térmica por chasis es jugar con un dado cargado.
Se recuperaron restaurando una curva de ventilador más agresiva para racks de producción, y luego aplicando políticas más silenciosas selectivamente solo donde las temperaturas de admisión y la densidad del chasis lo permitían, con alarmas térmicas ligadas a automatismos para revertir la política cuando se alcanzaran umbrales.
Micro-historia 3: La práctica aburrida pero correcta que salvó el día
Un equipo de servicios financieros tenía un hábito que parecía tedioso: cada manipulación de hardware requería una “verificación física” por dos personas. No solo “alguien firmó,” sino que dos pares de ojos confirmaban ítems como: pegatina retirada,
pasta aplicada, secuencia de apriete del disipador seguida, conectores de ventilador conectados e instalados los deflectores de flujo.
Durante una ventana de mantenimiento apresurada, tuvieron que reemplazar una CPU en un servidor que también albergaba servicios de almacenamiento sensibles a la latencia. El entorno era ruidoso, caliente y lleno de distracciones. El lugar exacto donde las pegatinas prosperan.
El primer técnico montó el disipador y empezó a cerrar el chasis; entonces la segunda persona preguntó la pregunta de la lista:
“¿La película de la placa fría está retirada?” Se detuvieron. Reabrieron. La película seguía ahí. Tomó diez segundos arreglarlo y salvó lo que habría sido un incidente desordenado con síntomas confusos.
Este es el tipo de práctica que no recibe aplausos. Gana uptime. También escala: cuando hay rotación y se suman personas nuevas, la lista de verificación es memoria institucional escrita en lenguaje llano.
Errores comunes: síntoma → causa raíz → solución
Los errores de sobrecalentamiento son previsibles. Eso es buena noticia: puedes construir salvaguardas. Aquí hay mapeos específicos que
cambian decisiones, no solo impresiones.
1) Ventiladores al 100%, la CPU aún llega a 95–100°C rápidamente → mala interfaz de placa fría → remontar, quitar film, repastar
- Síntoma: Rápida subida de temperatura; throttling en dmesg; ventiladores a todo volumen.
- Causa raíz: Pegatina protectora dejada, presión de montaje desigual, o pasta aplicada incorrectamente (demasiada, muy poca o contaminada).
- Solución: Apagar, quitar el disipador, limpiar con alcohol isopropílico, quitar la película, aplicar pasta correctamente, apretar en patrón cruzado al par especificado.
2) Temperaturas de CPU bien pero el sistema se reinicia bajo carga → VRM o chipset sobrecalentados → restaurar flujo de aire y revisar pads
- Síntoma: Temperatura del paquete CPU parece segura, pero SEL muestra avisos de VRM o eventos de “unidad de potencia”.
- Causa raíz: Falta de deflector de aire, ventilador muerto o pad térmico de VRM desalineado tras servicio.
- Solución: Reemplazar ventilador, restaurar deflectores/ductos, verificar disipadores y pads, asegurar diseño de presión del chasis.
3) Picos de latencia de almacenamiento, la CPU parece normal → throttling térmico NVMe → añadir disipadores/flujo, reubicar unidades
- Síntoma: Picos aleatorios de latencia IO; temperaturas NVMe 70–85°C; warning_temp_time en aumento.
- Causa raíz: Unidades sin flujo de aire, disipadores faltantes o colocadas detrás de GPUs calientes.
- Solución: Instalar disipadores NVMe adecuados, mejorar ruta de flujo de aire, usar paneles ciegos, considerar reubicar unidades de alto IO a bahías mejor refrigeradas.
4) Solo ciertas cargas desencadenan problemas → mezcla de instrucciones provoca pico térmico → poner límites de potencia o programar cargas
- Síntoma: Normal para la mayoría de tareas; falla con cómputo específico (matemáticas vectorizadas, compresión, cifrado, reconstrucciones pesadas).
- Causa raíz: La carga genera mayor consumo sostenido; el margen de refrigeración es insuficiente.
- Solución: Aplicar caps de potencia, afinar comportamiento turbo, programar trabajos pesados en ventanas más frescas o mejorar la refrigeración/flujo de aire.
5) Después de actualizar firmware, las temperaturas cambiaron → política de control de ventiladores cambiada → fijar política o re-ajustar curvas
- Síntoma: “La semana pasada iba bien,” sin cambios de hardware, pero los ventiladores ahora idlean más bajos y aumentan más tarde.
- Causa raíz: Una actualización de BMC/BIOS alteró las curvas de ventilador o la interpretación de sensores.
- Solución: Verificar ajustes de modo de ventilador, comparar con baseline, fijar a una política conocida y actualizar tus chequeos de automatización.
6) Un nodo del rack se sobrecalienta más que los vecinos → obstrucción local del flujo → arreglar cableado, paneles ciegos, puertas
- Síntoma: Mismos servidores, misma carga; uno corre más caliente.
- Causa raíz: Montón de cables bloqueando la entrada, paneles ciegos faltantes, obstrucción parcial o ventilador fallido.
- Solución: Restaurar flujo de aire frontal-trasero, reemplazar ventilador, re-rutar cables, instalar paneles ciegos.
Listas de verificación / plan paso a paso
Cuando sospechas sobrecalentamiento en producción (checklist de operaciones)
- Estabiliza el servicio: drena cargas, reduce concurrencia o falla por conmutación si es posible.
- Confirma térmicos: sensores + BMC/IPMI + logs. No confíes en una sola fuente.
- Mide throttling: frecuencia bajo carga, no en reposo.
- Determina alcance: nodo único vs flota vs rack.
- Mitiga de forma segura: tope temporal de potencia, modo de ventilador más alto o limitar cargas.
- Programa intervención manual: si hardware es nuevo/serviciado, asume causa física y planifica un apagado controlado.
- Captura para postmortem: SEL, dmesg, snapshots de sensores, tiempos de cargas.
Cuando montas o das servicio a un servidor (checklist de hardware)
- Quitar la película de la placa fría antes de que la pasta toque nada.
- Limpiar superficies (IHS y placa fría) con disolvente apropiado y paños sin pelusa.
- Aplicar pasta correctamente: método consistente, poca cantidad, sin burbujas, no reutilizar pasta vieja.
- Montar con presión uniforme: patrón cruzado, torque correcto, no “una esquina completamente apretada primero.”
- Confirmar conectores de ventilador/bomba conectados a los encabezados correctos de la placa base.
- Verificar piezas de flujo de aire: deflectores, carcasas, paneles ciegos, conductos.
- Ejecutar burn-in sostenido: al menos 20–30 minutos con carga real mientras se registran temperaturas.
- Registrar baseline: temperatura en reposo, temperatura en carga, RPM de ventiladores, ambiente, consumo de CPU.
Árbol de decisión “sospecha de pegatina” (rápido y decisivo)
- ¿Se tocó el disipador/CPU recientemente? Si sí, sospecha la interfaz primero.
- ¿Las temperaturas suben en minutos con carga modesta? Si sí, interfaz/bomba/ventilador probablemente.
- ¿Funcionan ventiladores/bomba? Si sí y aún hay sobrecalentamiento, la sospecha principal es el contacto físico.
- ¿Puedes mitigar con tope de potencia? Si sí, hazlo para ganar tiempo; luego programa un apagado e inspección.
Preguntas frecuentes (FAQ)
1) ¿Es realmente común el error de la pegatina en entornos corporativos?
Sí, especialmente cuando el hardware se monta o da servicio bajo presión de tiempo, o cuando los proveedores preensamblan y tu
equipo asume que las pruebas de aceptación lo habrán detectado. Las pruebas cortas no lo harán.
2) ¿No fallaría el sistema al arrancar si la pegatina queda puesta?
Normalmente arranca. Por eso es peligroso. En reposo, la CPU puede sobrevivir con pobre transferencia de calor. Bajo carga sostenida, no puede.
3) ¿Puede la pasta térmica “quemar” o compensar la pegatina?
No. La pasta no es magia. Reduce huecos microscópicos entre superficies metálicas. Una película plástica crea una barrera continua con mala conductividad y a menudo atrapa más aire.
4) ¿Cómo distingues pegatina de bomba muerta en un AIO?
Ambos se parecen: subida rápida de temperatura. Con una bomba muerta, puedes ver RPM de la bomba en 0 o anormales, y el radiador
permanece relativamente frío mientras el bloque de CPU se calienta. Los problemas de pegatina suelen mostrar un mal patrón de contacto de pasta cuando lo abres.
5) ¿Por qué el sobrecalentamiento a veces parece problemas de almacenamiento o red?
Porque el throttling aumenta la latencia en todas partes: retrasos en la planificación de CPU, retrasos en el manejo de interrupciones, retrasos en la presentación de IO. Añade throttling de NVMe y tienes una perfecta distracción.
6) ¿Cuál es un “burn-in” seguro para detectar esto sin arriesgar el hardware?
Una carga sostenida controlada de 20–30 minutos (estrés de CPU más IO realista si es nodo de almacenamiento) mientras se vigilan temperaturas,
RPM de ventiladores y banderas de throttling. Para si te acercas a umbrales críticos.
7) ¿Los servidores se protegen bien contra el sobrecalentamiento?
Lo intentan. El throttling térmico y los trips están diseñados para proteger el silicio, no tu tiempo de actividad. Un “apagado protegido” sigue siendo una interrupción, y trips repetidos pueden estresar componentes.
8) ¿Debería tener los ventiladores al máximo todo el tiempo para evitar esto?
No. Los ventiladores al máximo ocultan problemas y aumentan desgaste y ruido. Usa curvas de ventilador apropiadas para tu entorno y apóyate en
buen montaje, flujo de aire limpio y monitorización. Sube la política de ventilador solo como mitigación o donde esté validado.
9) ¿Qué debo monitorizar para detectar problemas térmicos temprano?
Temperatura del paquete CPU, frecuencia de CPU bajo carga, RPM de ventiladores, consumo de energía y eventos SEL del BMC. Para nodos de almacenamiento, añade
temperatura NVMe e indicadores de throttling.
10) ¿Cuál es la mejor corrección de proceso humano?
Un paso de verificación física por dos personas para cualquier trabajo en cooler/CPU, además de una breve prueba de carga sostenida con temperaturas registradas antes de devolver la caja a producción.
Próximos pasos prácticos
El sobrecalentamiento es una de esas clases de fallo donde la diferencia entre una historia graciosa y un incidente real es si lo tratas como una preocupación operativa de primera clase. La pegatina es graciosa una sola vez, y solo si ocurre en una caja no crítica.
Una idea para la fiabilidad parafraseada de W. Edwards Deming: “No puedes gestionar lo que no mides.” En térmicos, eso significa temperaturas, frecuencias, RPM de ventiladores y potencia—ligados a cambios y eventos de mantenimiento.
- Añade una prueba de aceptación térmica sostenida para nodos nuevos o servidos (con temperaturas registradas y comprobaciones de throttling).
- Instrumenta BMC/IPMI en tu monitorización para que las alarmas térmicas no queden tras una página de login.
- Codifica una lista de verificación física (incluyendo “quitar película de la placa fría”) y exige verificación por dos personas.
- Define un runbook de mitigación: drenar cargas, fijar topes temporales de potencia, subir política de ventiladores y luego programar reparación física.
- Audita lo básico del flujo de aire: paneles ciegos, orden del cableado, filtros de polvo y salud de ventiladores.
Si haces solo una cosa: la próxima vez que un nodo se sobrecaliente tras mantenimiento, deja de negociar con los logs y abre el chasis. A la pegatina no le importan tus paneles de control.