Calor, ventiladores y throttling: demuestra que es térmico (o no) con herramientas integradas

Cómo se manifiesta el “throttling térmico” en producción

El throttling térmico es el sistema protegiéndose a sí mismo reduciendo rendimiento: bajar la frecuencia de la CPU, limitar la potencia, ralentizar una GPU,
reducir el rendimiento de NVMe o, en casos extremos, forzar un apagado. No es un bug. Es una característica de seguridad. Tu problema es que a menudo
es invisible en la capa que estás observando.

La parte complicada: el sistema no anuncia “estoy limitando ahora” en un único lugar universal. Filtra pistas a través de:
estadísticas de frecuencia de CPU, logs del kernel, sensores de monitorización de hardware, datos SMART y contadores de rendimiento.
Reunirás esas pistas en un caso que puedas defender.

Los buenos operadores tratan lo “térmico” como una causa de fallo de primera clase, al mismo nivel que pérdida de paquetes y errores de disco.
No porque sea frecuente, sino porque cuando ocurre, crea confusión costosa.

Una cita, porque resume todo el trabajo: “La esperanza no es una estrategia.” — General Gordon R. Sullivan

Broma #1: Los ventiladores no “suben de revoluciones sin razón”. Suben porque el servidor tiene sentimientos sobre tu carga de trabajo.

Hechos interesantes y un poco de historia (porque explican las rarezas actuales)

• El throttling térmico es anterior a los servidores “modernos”. La era temprana de Pentium 4 de Intel introdujo gestión térmica agresiva tras la “carrera de velocidad de reloj” que convirtió el calor en un límite de primer orden.
• DVFS (escalado dinámico de voltaje y frecuencia) se volvió común en los 2000 cuando los portátiles obligaron a las CPUs a sobrevivir con sistemas de refrigeración pequeños; los servidores heredaron esos mecanismos.
• Turbo Boost cambió las expectativas. Como las frecuencias turbo son oportunistas, la “frecuencia base” no es el rendimiento real—hasta que la térmica te empuja hacia abajo.
• Los límites de potencia se convirtieron en política. Controles de potencia al estilo RAPL hicieron del “throttling” tanto una cuestión de presupuestos de energía del datacenter como de temperatura.
• NVMe introdujo sus propios estados térmicos. Muchas unidades tienen múltiples sensores de temperatura y umbrales de “aviso” vs “crítico”, además de curvas internas de throttling.
• El pasillo frío/pasillo caliente no es una sugerencia. El concepto surgió a medida que aumentó la densidad en racks; mezclar corrientes de aire convierte tu datacenter en un costoso experimento de convección.
• El control de ventiladores se movió al firmware. Los BMC modernos (IPMI/Redfish) a menudo anulan el control del ventilador desde el SO, por eso el truco de “ajustar velocidad de ventilador” desde el SO no funciona.
• La virtualización oscurece los síntomas térmicos. Las máquinas invitadas ven una CPU virtual y no ven directamente los eventos térmicos del host, así que “la VM está lenta” se vuelve una historia de detectives.

Guion de diagnóstico rápido (primero/segundo/tercero)

Primero: confirma si el rendimiento está limitado

1. Verifica el comportamiento actual de la frecuencia CPU (¿está atascada baja en todos los núcleos?).
2. Revisa mensajes del kernel sobre térmica/potencia (zonas térmicas disparadas, advertencias de throttling).
3. Comprueba “temperatura del paquete vs máximo” (¿estás cerca de TjMax o de los umbrales de advertencia del disco?).

Segundo: identifica qué componente es la víctima

• ¿Pico de latencia ligado a CPU? Mira límites de frecuencia, contadores de throttling y límites de potencia.
• ¿Pico de latencia de almacenamiento? Revisa SMART de NVMe y logs de throttling; correlaciona con latencia de I/O.
• ¿“Caídas misteriosas” de red? Revisa la temperatura de la NIC si está expuesta; también revisa throttling del host (el manejo de softirq se enlentece).

Tercero: prueba causalidad con correlación

• Correlaciona temperatura con frecuencia y latencia a lo largo del tiempo.
• Cambia una variable de forma segura: abre la puerta, aumenta la política de ventiladores, reduce el límite de potencia, mueve la carga o limita el turbo. Observa el efecto.
• Si la temperatura cambia y el rendimiento cambia al mismo ritmo, tienes la prueba.

Deja de hacer esto

No empieces reemplazando hardware. No empieces culpando al kernel. No empieces “ajustando” la app.
Primero demuestra si la máquina está siendo limitada físicamente.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son deliberadamente aburridas. Aburrido es bueno. Aburrido es repetible. Cada tarea incluye: un comando, qué significa una salida típica
y la decisión que tomas.

Task 1: Leer frecuencia de CPU en vivo (por núcleo) y detectar un tope

cr0x@server:~$ grep -H . /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 2>/dev/null | head
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:1200000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:1200000
/sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq:1200000
/sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:1200000
/sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq:1200000
/sys/devices/system/cpu/cpu5/cpufreq/scaling_cur_freq:1200000

Qué significa: Si todos los núcleos están anclados a una frecuencia baja (aquí ~1.2GHz) durante un período en que esperas carga, podrías estar limitado por potencia o térmica.
Si ves variación normal (núcleos subiendo/bajando) eso suele estar bien.

Decisión: Si está anclado bajo, comprueba inmediatamente temperaturas y contadores de throttling antes de tocar la aplicación.

Task 2: Comprobar política de frecuencia min/max (¿te estás auto-limitando?)

cr0x@server:~$ for f in /sys/devices/system/cpu/cpu0/cpufreq/scaling_{min,max}_freq; do echo "$f: $(cat $f)"; done
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq: 800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: 1800000

Qué significa: La política del SO dice “no superar 1.8GHz.” Eso puede ser intencional (ahorro de energía) o accidental (config mal, governor equivocado, política de cloud).

Decisión: Si scaling_max_freq está por debajo de lo esperado, arregla la política primero. La térmica aún puede existir, pero no confundas “tope por admin” con “tope por hardware”.

Task 3: Inspeccionar governor/driver de CPU (¿quién manda?)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
intel_pstate

Qué significa: intel_pstate se comporta distinto a acpi-cpufreq. Algunos ajustes y expectativas cambian. En AMD verás amd-pstate o similar.

Decisión: Usa herramientas apropiadas al driver (por ejemplo, powercap para límites de paquete Intel) y no cargo-cultes tweaks de sysfs de otra plataforma.

Task 4: Extraer mensajes del kernel sobre eventos térmicos

cr0x@server:~$ dmesg -T | egrep -i 'thermal|thrott|overheat|trip|powercap' | tail -n 12
[Mon Feb  5 10:14:21 2026] CPU0: Core temperature above threshold, cpu clock throttled (total events = 17)
[Mon Feb  5 10:14:21 2026] CPU2: Core temperature above threshold, cpu clock throttled (total events = 17)
[Mon Feb  5 10:14:22 2026] CPU0: Package temperature/speed normal
[Mon Feb  5 10:17:03 2026] nvme nvme0: temperature above threshold, throttling

Qué significa: Este es tu indicio contundente cuando aparece. No todos los sistemas registran limpio, pero cuando lo hacen, es difícil discutir.

Decisión: Si ves eventos de throttling repetidos, deja de debatir y empieza a mitigar: flujo de aire, política de ventiladores, límites de potencia, ubicación de carga.

Task 5: Leer zonas térmicas vía sysfs (funciona incluso sin herramientas sofisticadas)

cr0x@server:~$ for z in /sys/class/thermal/thermal_zone*; do echo -n "$(cat $z/type) "; awk '{print $1/1000 "°C"}' $z/temp; done | head
x86_pkg_temp 92.0°C
acpitz 54.0°C

Qué significa: x86_pkg_temp es la temperatura del paquete CPU. 92°C está “cerca del precipicio” en muchas piezas (depende de TjMax).
acpitz suele ser una zona de placa base/ACPI, menos directamente ligada al throttling.

Decisión: Si la temperatura del paquete es alta y el rendimiento es bajo, trátalo como térmico hasta que se demuestre lo contrario.

Task 6: Obtener detalle de sensores (ventiladores + temperaturas) con lm-sensors

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +94.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +92.0°C  (high = +80.0°C, crit = +100.0°C)
Core 1:        +93.0°C  (high = +80.0°C, crit = +100.0°C)

nct6779-isa-0a20
Adapter: ISA adapter
fan1:        3200 RPM
fan2:        3100 RPM
SYSTIN:       +44.0°C
CPUTIN:       +73.0°C

Qué significa: Esto muestra umbrales y valores actuales. Fíjate en high vs crit. “High” suele ser donde empieza el throttling.
Ventiladores a 3200 RPM aún pueden ser “insuficientes” dependiendo del chasis y obstrucciones.

Decisión: Si los ventiladores están altos pero las temperaturas siguen subiendo, sospecha de la ruta de flujo de aire, filtros obstruidos, paneles faltantes o disipador mal asentado.

Task 7: Comprobar capado de potencia (Intel RAPL vía powercap)

cr0x@server:~$ grep -H . /sys/class/powercap/intel-rapl:*/constraint_*_power_limit_uw 2>/dev/null | head
/sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw:65000000
/sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uw:85000000

Qué significa: Los límites de potencia (aquí 65W/85W) pueden imponer throttling incluso cuando las temperaturas están bien. Eso es “throttling por potencia”, no estrictamente térmico.

Decisión: Si la frecuencia es baja pero las temperaturas son moderadas, revisa límites de potencia y políticas del datacenter antes de culpar a la refrigeración.

Task 8: Observar contadores de throttling de CPU (MSR Intel vía turbostat)

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 2 --num_iterations 3
Avg_MHz  Busy%  Bzy_MHz  TSC_MHz  PkgTmp  PkgWatt  CorWatt
1280     72.15  1773     2600     96      62.4     38.1
1275     73.02  1740     2600     97      62.1     38.5
1269     71.88  1729     2600     97      61.9     37.9

Qué significa: Busy% es alto (hay trabajo), pero Avg_MHz es bajo comparado con TSC_MHz (nominal).
PkgTmp es 96°C: probablemente estás en territorio de gestión térmica.

Decisión: Si PkgTmp sube y Avg_MHz cae bajo carga, ve a remediaciones de refrigeración/potencia, no a perfilado de la aplicación.

Task 9: Usar perf para ver si ciclos y frecuencia coinciden con expectativas

cr0x@server:~$ sudo perf stat -a -e cycles,instructions,msr/aperf/,msr/mperf/ sleep 5

 Performance counter stats for 'system wide':

    12,345,678,901      cycles
     7,654,321,098      instructions              #    0.62  insn per cycle
     9,120,000,000      msr/aperf/
    19,500,000,000      msr/mperf/

       5.001234567 seconds time elapsed

Qué significa: La razón aperf/mperf aproxima la frecuencia media relativa a la nominal. Aquí es ~0.47, lo que significa que la CPU promedió ~47% del nominal.
Eso es consistente con throttling o bajada fuerte de reloj.

Decisión: Si aperf/mperf baja cuando suben las temperaturas, tienes una prueba cuantitativa de “tope de frecuencia” para tu informe de incidente.

Task 10: Comprobar temperatura NVMe y advertencias con SMART

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'Temperature:|Warning|Critical|Thermal|throttle' -n
31:Temperature:                        78 Celsius
32:Temperature Sensor 1:               81 Celsius
33:Temperature Sensor 2:               76 Celsius
54:Warning  Comp. Temperature Time:    12
55:Critical Comp. Temperature Time:    0

Qué significa: Las unidades registran tiempo acumulado por encima de umbrales de advertencia/críticos. “Warning time” no ser cero significa que esto no es teórico.
Diferentes sensores pueden representar controlador vs NAND vs compuesto.

Decisión: Si el tiempo de advertencia incrementa durante la ventana de latencia, trata el almacenamiento como restringido térmicamente aunque la CPU parezca bien.

Task 11: Correlacionar latencia de almacenamiento con temperatura (iostat + muestreo smartctl)

cr0x@server:~$ iostat -x 1 5 nvme0n1
Linux 6.5.0 (server) 	02/05/2026 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    4.22    8.80    0.00   74.88

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
nvme0n1         120.0   340.0  5120.0 18240.0    9.2   18.5  98.0

Qué significa: await en ~18ms y %util cerca de 100% en NVMe bajo throughput moderado puede ser sospechoso.
Puede ser colas, comportamiento de firmware o throttling. Es una pista, no un veredicto.

Decisión: Si la latencia de iostat sube al mismo tiempo que las temperaturas SMART cruzan umbrales de advertencia, prioriza el flujo de aire hacia las bahías de unidad y revisa disipadores/ductos.

Task 12: Vigilar logs del sistema por eventos térmicos y enlaces PCIe

cr0x@server:~$ journalctl -k --since "30 min ago" | egrep -i 'thermal|thrott|nvme|pcie|AER|overheat' | tail -n 30
Feb 05 10:14:21 server kernel: CPU0: Core temperature above threshold, cpu clock throttled
Feb 05 10:17:03 server kernel: nvme nvme0: temperature above threshold, throttling
Feb 05 10:17:04 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0

Qué significa: Los errores corregidos AER de PCIe a veces aparecen cuando las cosas están calientes (no siempre—existen ranuras y tarjetas defectuosas).
El calor puede agravar la integridad de la señal marginal.

Decisión: Si térmico + AER coocurren, trátalo como un problema del entorno de hardware: vuelve a asentar, revisa flujo de aire, busca paneles faltantes, valida la refrigeración de la tarjeta.

Task 13: Comprobar vista de sensores BMC/IPMI (ventiladores/temperaturas desde hardware)

cr0x@server:~$ sudo ipmitool sdr type temperature | head
CPU1 Temp        | 94 degrees C      | ok
CPU2 Temp        | 93 degrees C      | ok
Inlet Temp       | 29 degrees C      | ok
Exhaust Temp     | 57 degrees C      | ok

Qué significa: “ok” no significa “saludable”. Significa “no supera el umbral de alarma del proveedor.”
El delta entre inlet y exhaust te dice si la caja está sacando calor o simplemente cocinando internamente.

Decisión: Si el inlet es razonable pero la CPU está alta, sospecha de la ruta de flujo interna o del contacto/pasta del disipador. Si el inlet es alto, el problema es la sala.

Task 14: Confirmar RPM de ventiladores y si el control de ventiladores está atascado

cr0x@server:~$ sudo ipmitool sdr type fan | head
FAN1            | 3200 RPM           | ok
FAN2            | 3100 RPM           | ok
FAN3            | 800 RPM            | ok
FAN4            | 0 RPM              | nr

Qué significa: Un ventilador a 0 RPM con estado “nr” (no legible / no presente) podría ser esperado (bahía vacía) o un ventilador muerto.
RPM mixtas pueden indicar una pared de ventiladores con una unidad fallida o un problema de control por zonas.

Decisión: Si falta un ventilador requerido o está muerto, no lo “monitores”. Cámbialo. Los problemas térmicos no son lugar para filosofar.

CPU: límites de frecuencia, límites de paquete y las mentiras de tu panel

Throttling no siempre es “temperatura demasiado alta”

La gente dice “throttling térmico” como atajo de “la CPU se calentó”. En la práctica, el rendimiento puede ser limitado por:
temperatura, límites de potencia de paquete, límites de corriente, temperatura del VRM o políticas de firmware (especialmente en servidores con control BMC estricto).
El síntoma es el mismo: la CPU no corre tan rápido como pagaste.

Tus paneles a menudo muestran la utilización de CPU, no la capacidad de la CPU.
Una CPU al 70% ocupada a 1.2GHz no es la misma máquina que una CPU al 70% ocupada a 3.2GHz.
La utilización sin frecuencia es una media verdad que causa malas decisiones.

Probar que es térmico: la cadena mínima de evidencia creíble

Un conjunto de pruebas creíble es:

• Temperatura del paquete CPU cerca de su límite (o aumentando hacia él).
• Frecuencia (o la razón aperf/mperf) cayendo conforme sube la temperatura.
• Logs del kernel/BMC mostrando eventos térmicos, o incremento del tiempo de advertencia SMART.
• Síntoma de rendimiento alineado en tiempo (pico de latencia, caída de throughput, ampliación de cola de latencias).

Si solo tienes uno de estos, tienes sospecha. Si tienes tres, tienes un caso.

Cuando no es térmico: los impostores que “parecen throttling”

• Cupo de CPU / límites de cgroup: los contenedores pueden estar capados y parecer “atascados” con bajo rendimiento efectivo sin problema de temperatura.
• Políticas de frecuencia: governors conservadores, ajustes de BIOS o políticas de proveedor cloud.
• Tormentas de interrupciones: alta carga de softirq puede crear latencia mientras la “CPU inactiva” parece alta por artefactos de medición o tiempo steal.
• Mala colocación NUMA: picos de latencia de memoria que parecen “CPU lenta”.

Una acción que suele ser correcta

Si sospechas throttling de CPU, recoge evidencia primero, luego reduce temporalmente el turbo (o limita la frecuencia máxima) y observa si el sistema se estabiliza.
Eso suena contraintuitivo—¿por qué reducir rendimiento?—pero la estabilidad es más importante que el pico. Si un pequeño tope evita que la CPU rebote contra límites térmicos,
a menudo obtienes un mayor rendimiento sostenido.

NVMe y discos: cuando la “lentitud” de almacenamiento es temperatura

El throttling NVMe es real, y no es sutil

Las unidades NVMe pueden throttlear duro cuando se calientan. Los controladores se protegen primero, y tu aplicación experimenta eso como “latencia I/O aleatoria”.
En cargas mixtas verás la latencia en cola explotar mientras el throughput promedio solo empeora ligeramente. Ese perfil es la pesadilla para bases de datos.

SMART suele proporcionar la prueba más defendible: temperatura compuesta actual, temperaturas por sensor y el tiempo acumulado por encima de umbrales.
Si el tiempo de advertencia incrementa durante la ventana del incidente, puedes dejar de discutir y empezar a arreglar el flujo de aire en el área de unidades.

Qué comprobar además de la temperatura

• Disipadores y ductos de flujo: Algunos chasis asumen una ruta de flujo específica; retirar paneles o cambiar risers puede romperla.
• Colocación de unidades: Una unidad “caliente” junto a una NIC o GPU caliente puede funcionar más cálida que las vecinas.
• Cambios en ancho/velocidad de enlace PCIe: Raro, pero problemas térmicos/mecánicos pueden causar reentrenamiento de enlace; los mensajes AER ayudan.
• Comportamiento de firmware: Las unidades tienen curvas térmicas distintas; dos unidades “idénticas” pueden throttlear de forma muy diferente.

Broma #2: Las unidades NVMe son rápidas hasta que descubren la termodinámica, momento en que se vuelven una excelente lección de humildad.

Ventiladores, flujo de aire y la realidad del chasis: la parte física

Los ventiladores pueden “funcionar” y aún así fallarte

“RPM de ventilador parece bien” no es una condición de victoria. RPM es solo rotación. No garantiza volumen de flujo, presión ni dirección correcta por la ruta adecuada.
Un servidor es un sistema de conductos. Paneles faltantes, cables mal enrutados, disipadores aftermarket e incluso un conducto de aire ligeramente desalineado pueden convertir una ruta de flujo diseñada
en una fiesta de recirculación.

La temperatura de entrada es el KPI oculto

La mayoría de operadores se obsesionan con la temperatura de la CPU y ignoran la temperatura de entrada. La entrada es lo que tu sistema de enfriamiento realmente entrega.
Si la entrada es alta, tu servidor puede estar perfectamente ensamblado y aun así hacer throttling.
Si la entrada es baja pero la CPU está alta, tu servidor está mal ensamblado (o el contacto/pasta del disipador es incorrecto, o la pared de ventiladores es débil).

Errores en pasillo frío/pasillo caliente aparecen como “throttling aleatorio”

Cuando el aire frío se mezcla con el escape caliente, no obtienes “enfriamiento algo peor”. Obtienes condiciones inestables:
ráfagas de throttling cuando la carga sube, luego recuperación, luego throttling otra vez. Parece jitter. Es jitter.
Y tiende a aparecer primero en los nodos más densos térmicamente: cajas con mucho almacenamiento, nodos de computación con turbo alto o cualquier cosa con aceleradores.

El control de ventiladores por firmware puede sabotear las suposiciones del SO

En muchos servidores, el BMC posee el control de ventiladores. El SO puede leer temperaturas pero no siempre puede ordenar ventiladores de forma significativa.
Si tu equipo intenta “ajustar PWM desde Linux” en una plataforma gestionada por BMC, perderás horas.
El enfoque correcto es revisar lecturas de sensores BMC y políticas de ventiladores, luego cambiar el modo de ventiladores usando interfaces soportadas por el proveedor.

Tres micro-historias corporativas (anonimizadas, plausibles y dolorosamente educativas)

Micro-historia #1: El incidente provocado por una suposición equivocada

Una empresa mediana ejecutaba una API de pagos en un clúster de servidores “idénticos”. Sacaron una nueva versión y la latencia p99 se duplicó en una AZ.
El on-call hizo lo que muchos hemos hecho: culpar la versión. Empezó el rollback de inmediato.

El rollback no lo solucionó. La utilización de CPU parecía normal. La memoria parecía normal. Las tasas de error no aumentaron. El único síntoma obvio era que
un rack tenía un patrón raro: el throughput caía en picado cada tarde y volvía por la noche. Alguien sugirió “vecino ruidoso” en el HVAC del edificio. Otro sugirió firmware de NIC malo. Un tercero dijo “es el scheduler del kernel otra vez”.

La suposición equivocada fue sutil: el equipo asumió que si la CPU hacía throttling, lo verían en sus paneles estándar.
No recopilaron frecuencia ni datos térmicos. La utilización por sí sola parecía saludable, porque la CPU estaba ocupada—en una frecuencia reducida.

Cuando finalmente muestrearon /sys/class/thermal y ejecutaron turbostat, la historia encajó:
la temperatura del paquete se mantuvo cerca del umbral alto y el MHz medio estaba muy por debajo del nominal durante la ventana del incidente.
La temperatura de entrada del BMC también era alta, pero aún “ok” según los umbrales del proveedor. Las losetas del pasillo frío del rack habían sido reubicadas durante trabajos no relacionados,
y el rack estaba tomando aire más cálido.

La solución no fue heroica: restaurar flujo de aire, añadir paneles de cierre y ajustar la colocación de losetas. La versión era inocente.
La lección quedó: los paneles que ignoran frecuencia y térmicas generan falsa confianza.

Micro-historia #2: La optimización que salió mal

Otra empresa corría cargas analíticas “por lotes” que amaban las frecuencias turbo. Alguien tuvo una idea brillante:
poner el governor de rendimiento, habilitar turbo agresivo y levantar algunos límites de potencia “porque las CPUs lo aguantan”.
Durante una semana celebraron trabajos más rápidos.

Luego llegó el pico mensual. La carga sostenida llevó a las CPUs a una oscilación térmica: boost fuerte, alcanzar límite térmico, throttling, enfriar ligeramente,
volver a boost. El rendimiento medio disminuyó comparado con los ajustes conservadores previos, y las latencias en cola se volvieron caóticas.
Peor aún, las NVMe en el mismo chasis se calentaron más porque la curva de ventiladores ahora estaba afinada para picos de CPU, no para calor sostenido en el chasis.

El on-call vio los síntomas como “bloqueos I/O aleatorios”. Ajustaron el stack de almacenamiento: cambios de scheduler, profundidades de cola, tweaks de sistema de archivos.
Algunos cambios hicieron que los gráficos se vieran distintos pero no estabilizaron el sistema. La optimización convirtió el comportamiento térmico en un bucle de realimentación,
y el equipo de almacenamiento fue culpado porque sus métricas gritaban más fuerte.

La solución fue dejar de perseguir el pico y diseñar para lo sostenido: capar la frecuencia máxima de CPU ligeramente por debajo del precipicio térmico, establecer una política de ventiladores más agresiva
para cargas sostenidas y añadir monitoreo de tiempo de advertencia de NVMe. Los trabajos volvieron a ser previsiblemente rápidos. No tan “explotados”, pero confiablemente rápidos.

La lección: subir sin margen térmico es como hacer overclock con traje puesto. Impresiona hasta que intentas respirar.

Micro-historia #3: La práctica aburrida pero correcta que salvó el día

Un proveedor SaaS de salud tenía un ritual: al desplegar un nuevo rack, registraban temperaturas de entrada/salida, líneas base de ventiladores y temperaturas SMART
bajo una prueba de carga controlada. También mantenían una aburrida hoja de cálculo de valores “normales” por modelo de chasis.
A nadie le encantaba. Parecía trabajo administrativo.

Seis meses después, un clúster de bases de datos empezó a mostrar latencia de escritura elevada en solo dos nodos. No lo suficiente para alertas constantes—pero lo bastante ominoso.
El equipo comparó el tiempo de advertencia de temperatura NVMe actual con la línea base y notó que estaba acumulándose solo en esos dos nodos.
Las temperaturas de CPU estaban bien. Las de entrada también. Aun así, las unidades estaban calientes.

Porque tenían líneas base, no discutieron qué significaba “caliente”. Abrieron el chasis y encontraron una pieza de conducto de aire faltante
tras un mantenimiento previo. El flujo de aire estaba esquivando el área de unidades. Las unidades se estaban cocinando lentamente.

Reemplazaron el conducto, repitieron la prueba controlada y el tiempo de advertencia SMART dejó de acumularse. La latencia se normalizó.
No hubo actualización de firmware. No hubo tuning de sistema de archivos. No hubo sala de guerra a medianoche.

La lección: las líneas base aburridas convierten “rendimiento misterioso” en “reemplaza el plástico faltante y a dormir”.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: CPU está “idle” pero las solicitudes son lentas

Causa raíz: La CPU está throttled; la utilización se mide respecto a la capacidad actual, no a la capacidad esperada. O la carga es sensible a latencia y espera en un núcleo limitado.

Solución: Añade monitoreo de frecuencia/aperf-mperf; confirma con turbostat. Arregla la refrigeración o los límites de potencia. Deja de usar solo utilización para declarar victoria.

2) Síntoma: Acantilados de rendimiento periódicos a la misma hora cada día

Causa raíz: Variaciones ambiente/temperatura de entrada (horarios del HVAC, recirculación de pasillo caliente, exposición solar cerca de pared exterior, equipo adyacente encendiéndose).

Solución: Revisa tendencias de temperatura de entrada en BMC; correlaciona con temperaturas CPU/NVMe. Arregla gestión de flujo de aire, colocación de losetas, contención o ajustes del CRAC.

3) Síntoma: Picos de latencia NVMe durante escrituras intensas; throughput parece “más o menos bien”

Causa raíz: Sobrecalentamiento del controlador de la unidad y entrada en throttling; la latencia en cola se destroza primero.

Solución: Usa smartctl para tiempo de advertencia y sensores; mejora flujo de aire/disipadores en unidades; considera reubicar unidades lejos de componentes calientes.

4) Síntoma: Ventiladores ruidosos constantemente, incluso a baja carga

Causa raíz: Política de ventiladores del BMC en modo estático alto, un sensor con lectura faltante, o un “failsafe full speed” activado por un sensor defectuoso/ausente.

Solución: Revisa IPMI SDR para sensores “nr”; verifica ajustes del BMC. Reemplaza sensores/ventiladores defectuosos; restaura el modo correcto de ventiladores.

5) Síntoma: Después de actualizar el kernel, el sistema “empezó a hacer throttling”

Causa raíz: Cambió el driver/governor de frecuencia, o una nueva política térmica interactúa distinto con el firmware. A veces solo expuso una refrigeración marginal existente.

Solución: Confirma el driver (intel_pstate/acpi-cpufreq/amd-pstate) y la política de max freq; compara temperaturas y contadores de throttling pre/post. Ajusta BIOS/OS deliberadamente.

6) Síntoma: Solo un nodo del clúster está lento

Causa raíz: Obstrucción de flujo de aire local (racimo de cables, panel faltante, filtro de polvo), ventilador fallando, disipador mal asentado o disposición de dispositivos que genera más calor.

Solución: Compara inlet/exhaust en BMC, RPM de ventiladores y temperaturas de componentes contra nodos hermanos. Inspecciona físicamente y restaura la integridad del flujo de aire del chasis.

7) Síntoma: iowait sube, pero los discos no muestran errores

Causa raíz: Throttling térmico en NVMe o en el controlador; o throttling de CPU que enlentece la ruta de envío/completado de I/O.

Solución: Correlaciona await de iostat con temperatura/tiempo de advertencia NVMe y frecuencia CPU. Arregla el cuello de botella térmico; no “tunes” el iowait.

8) Síntoma: El rendimiento empeora tras “hacer los ventiladores más silenciosos”

Causa raíz: La configuración acústica agresiva redujo la reserva de refrigeración; el sistema ahora alcanza límites térmicos bajo carga sostenida.

Solución: Establece un perfil de ventiladores orientado a rendimiento/térmica; valida bajo carga sostenida. El silencio está bien, pero los SLOs lo están más.

Listas de verificación / plan paso a paso

Paso a paso: demuestra o descarta throttling térmico en 20 minutos

1. Captura la ventana de síntoma. Anota hora, carga y qué nodos están afectados. Si es solo un nodo, prioriza causas físicas.
2. Registra la frecuencia CPU ahora. Lee scaling_cur_freq y la política (scaling_max_freq).
3. Registra la temperatura del paquete CPU ahora. Usa /sys/class/thermal y sensors. Si la temperatura del paquete es alta, ya estás cerca.
4. Revisa logs en busca de evidencia térmica. dmesg y journalctl -k por mensajes térmicos/throttling/NVMe.
5. Cuantifica con contadores. Usa turbostat y/o perf stat para la razón aperf/mperf.
6. Si el almacenamiento está involucrado, revisa SMART. Especialmente el tiempo de advertencia de NVMe.
7. Comprueba inlet/exhaust y RPM de ventiladores desde BMC. IPMI SDR suele ser más fiable que sensores del SO en servidores.
8. Correlaciona. Si temp↑ y frecuencia↓ y latencia↑ al mismo tiempo, llámalo térmico.
9. Mitiga de forma segura. Reduce temporalmente el turbo o migra carga; aumenta el perfil de ventiladores; arregla el flujo de aire. Luego vuelve a probar.
10. Documenta. Captura salidas de comandos y marcas de tiempo. Los problemas térmicos se repiten si no institucionalizas la solución.

Qué estandarizar en la flota (aburrido, escalable, efectivo)

• Monitorear temperatura del paquete CPU, frecuencia efectiva de CPU (o aperf/mperf) y eventos de throttling donde estén disponibles.
• Monitorear temperatura de entrada del BMC y deber/RPM de ventiladores por zona.
• Monitorear temperatura compuesta NVMe y tiempo de temperatura de advertencia/crítico.
• Alertar sobre “tope de frecuencia sostenido” en lugar de “alta temperatura” sola. El calor solo es problema cuando cambia rendimiento o fiabilidad.
• Mantener una línea base por chasis bajo una prueba estándar después del aprovisionamiento y tras cualquier mantenimiento que abra el chasis.

Señales de alarma que significan “ve a ver el hardware”

• Un nodo difiere materialmente de sus hermanos en delta de temperatura de entrada o RPM de ventiladores.
• Tiempo de advertencia SMART subiendo en solo una unidad o un nodo.
• Mensajes térmicos en logs del kernel agrupados en una ventana temporal específica.
• Frecuencia efectiva de CPU colapsando bajo carga moderada.

Preguntas frecuentes

1) ¿Cómo sé si es throttling o simplemente baja utilización?

Mide frecuencia (o aperf/mperf). Si la carga está ocupada y la frecuencia está atascada baja, tienes un tope. Luego revisa temperaturas/logs para clasificarlo como térmico o política de potencia.

2) ¿Por qué la utilización CPU parece normal durante el throttling?

La utilización es “tiempo no inactivo”, no “qué tan rápido corrió la CPU”. Una CPU limitada puede estar 90% ocupada y aun así entregar mucho menos trabajo por segundo.

3) ¿Puede ocurrir throttling térmico sin mensajes en los logs?

Sí. Algunas plataformas no registran claramente, o los logs se limitan por tasa. Por eso corroboras con temperaturas, frecuencia y contadores como aperf/mperf.

4) ¿Es lo mismo limitar por potencia que throttling térmico?

Causa distinta, mismo síntoma: reducción de rendimiento. Los límites de potencia pueden desencadenar reducción de frecuencia incluso a temperaturas seguras. Diagnostica con powercap/RAPL y lecturas de turbostat sobre potencia.

5) ¿Por qué solo las unidades NVMe hacen throttling mientras la CPU está bien?

Las bahías de disco pueden ser una zona de flujo separada. Además, los controladores NVMe son pequeños y con alta densidad térmica; pueden alcanzar límites mientras la CPU aún tiene margen.

6) ¿Debería aumentar permanentemente la velocidad de los ventiladores?

Si estás en un datacenter, “más ruido permanente” a veces es aceptable, pero no es una solución de raíz. Prefiere restaurar el flujo de aire diseñado (paneles, conductos, filtros) y arreglar la temperatura de entrada.

7) Mis ventiladores de portátil están ruidosos pero el rendimiento sigue malo. ¿Es térmico?

A menudo sí, pero los portátiles también alcanzan límites del adaptador de corriente y políticas de batería. Revisa zonas térmicas, luego política de frecuencia. Si la frecuencia está capada baja aun cuando está fría, es política o potencia.

8) ¿Cuál es la mejor métrica para alertar?

“Frecuencia efectiva baja sostenida bajo carga sostenida” es un indicador fuerte. Combínalo con temperatura de paquete y tiempo de advertencia de NVMe para cobertura.

9) ¿Por qué mejora el rendimiento si capeo la frecuencia máxima un poco más baja?

Porque evitas la oscilación. Un 2.8GHz estable puede superar a un rebote caótico entre 3.6GHz y 1.2GHz cuando consideras comportamiento de caché, colas y latencia en cola.

10) ¿Cómo se lo pruebo a alguien que insiste en que es la aplicación?

Lleva correlación: marcas de tiempo de temperatura/frecuencia tope y latencia. Muestra una mitigación controlada (mejorar refrigeración o reducir turbo) que mejora inmediatamente el rendimiento sin cambios en el código.

Conclusión: qué hacer la semana que viene (no algún día)

Los problemas térmicos no necesitan misticismo. Necesitan evidencia y el hábito de revisar la capa correcta primero.
Si no te llevas nada más: deja de diagnosticar rendimiento sin frecuencia y temperatura en la misma vista.

Pasos prácticos siguientes:

• Añade recolección a nivel host para temperatura de paquete CPU, frecuencia efectiva (aperf/mperf o derivado de turbostat) y mensajes térmicos del kernel.
• Añade recolección SMART de NVMe para temperatura compuesta y tiempo de temperatura de advertencia/crítico.
• Establece líneas base de temperatura de entrada/salida y RPM de ventiladores después del aprovisionamiento y tras cualquier mantenimiento que abra el chasis.
• Crea un runbook de on-call que empiece con el guion de diagnóstico rápido: tope → componente → correlación → mitigación.
• Cuando encuentres un problema térmico, arregla errores de diseño de flujo de aire (paneles, conductos, filtros) antes de perseguir perillas de ajuste.

Tus sistemas funcionan con software, pero fallan por la física. Trata al calor como una dependencia de primera clase y dejará de sorprenderte a las 2 a.m.