Pasta térmica por todas partes: cuando el entusiasmo vence a la física

La física con la que no se puede negociar

La pasta térmica (TIM: material de interfaz térmica) no es “un conductor mejor que el metal.” Es todo lo contrario. Existe porque las superficies metálicas reales no son planas.
Si acercas el difusor térmico de una CPU a un disipador, no obtienes contacto perfecto. Obtienes picos microscópicos que tocan y un montón de aire atrapado en los valles.
El aire es un pésimo conductor. La pasta es “menos pésima que el aire”, así que rellena los huecos.

El objetivo no es una capa gruesa. El objetivo es una capa fina y continua que desplace el aire manteniendo el contacto metal-con-metal lo más alto posible. Si añades demasiado
compuesto, aumentas el espesor de la capa, y como la pasta conduce peor que el cobre o el aluminio, tu resistencia térmica sube. Ese es el primer y más común fallo de tipo
“el entusiasmo vence a la física”.

El segundo fallo es mecánico: la pasta es resbaladiza. El exceso puede cambiar cómo se asienta el disipador. Un cooler ligeramente inclinado o con par de apriete desigual puede crear
un patrón de contacto que parece correcto a simple vista pero que genera un punto caliente en un clúster de núcleos bajo carga AVX. Las CPUs modernas se protegen con
throttling, pero “protegido” sigue significando “más lento”, y en sistemas distribuidos, lo más lento es contagioso.

El tercer fallo es la contaminación. La mayoría de las pastas son nominalmente no conductoras eléctricamente, pero “no conductora” no es “segura para untar sobre componentes diminutos.”
Algunas pastas son algo capacitivas; otras contienen metales; algunas se vuelven conductoras cuando se contaminan o envejecen. E incluso si la pasta en sí es eléctricamente
inofensiva, atrae polvo y fibras, y complica la inspección y la retrabajo.

Aquí está la verdad operativa: si el comportamiento térmico de un servidor cambia después de un repaste, asume que lo empeoraste hasta que se demuestre lo contrario. Eso no significa
que seas un inútil. Significa que el sistema ya funcionaba, y tú cambiaste múltiples variables a la vez: espesor de interfaz, presión de montaje, curvas de ventilador (a menudo),
y flujo de aire (tuviste la tapa quitada). Empieza por la medición, no por la intuición.

Una cita que debería estar en la pared de todo equipo de operaciones, de Richard Feynman:
Para que una tecnología tenga éxito, la realidad debe preceder a las relaciones públicas, porque la naturaleza no puede ser engañada.
Es breve, ruda y cierta.

Broma #1: La pasta térmica es como el perfume—si la ves desde el otro lado de la sala, has usado demasiado.

Cómo se ve lo correcto (y por qué no existe un “guisante” universal)

Los consejos de Internet adoran el “punto del tamaño de un guisante.” No está mal en espíritu, pero es incompleto. Las CPUs tienen diferentes disposiciones del dado bajo el difusor.
Los disipadores aplican distintas distribuciones de presión. Algunos sockets son rectangulares y largos (HEDT y plataformas de servidor), lo que significa que el método de “un punto”
puede dejar las esquinas sin cobertura. Una línea fina o una X puede ser mejor para huellas IHS grandes.

El enfoque sensato es aburrido: usa un método conocido por plataforma, aplica un torque consistente y valida con una comprobación del patrón de contacto cuando cambias cooler o
tipo de pasta. Si trabajas en flota, estandariza. La consistencia vence al arte artesanal de la pasta.

Por qué sigue sobreviviendo la idea “más pasta = mejor refrigeración”

Parece intuitivo: más material entre dos cosas significa más transferencia. Eso es cierto cuando el material es mejor que la brecha. La brecha es aire (horrible), así que el primer
poquito de pasta ayuda mucho. Después de eso, ya no estás reemplazando aire. Estás reemplazando contacto metálico por una capa de pasta. Y ahora pagas por ello.

En términos de servidores: la pasta es como una caché. Un poco está bien. Toda la memoria fingiendo ser caché es solo… memoria.

Hechos y contexto histórico (la versión sin mitos)

• Hecho 1: La electrónica de alta potencia temprana usaba grasas y aceites como materiales de interfaz décadas antes de que el repaste en PCs de consumo se hiciera hobby.
• Hecho 2: El “compuesto térmico” se volvió común en PCs cuando la densidad de potencia de las CPU aumentó y la discrepancia entre superficies que parecen lisas y la planitud real importó.
• Hecho 3: Incluso las superficies metálicas pulidas tienen asperidades microscópicas; la suavidad óptica no es suavidad térmica.
• Hecho 4: La conductividad típica de la pasta térmica es mucho menor que la del cobre; su valor está en desplazar aire, no en superar al metal.
• Hecho 5: Existen materiales de cambio de fase (pads que se ablandan/funden ligeramente a temperatura de operación) para simplificar la consistencia en ensamblaje en fabricación.
• Hecho 6: “Pump-out” es un fenómeno real: el ciclo térmico y el estrés mecánico pueden migrar la pasta fuera del área de mayor calor con el tiempo.
• Hecho 7: Algunas pastas son eléctricamente conductoras (notablemente muchos compuestos de metal líquido), y requieren aislamiento, enmascarado y un mayor estándar de mano de obra.
• Hecho 8: Muchos disipadores de servidor están diseñados para una presión de montaje y un flujo de aire específicos; cambiar a una solución “aftermarket” puede romper el modelo térmico.
• Hecho 9: El throttling térmico es más agresivo y granular en CPUs modernas; puedes perder rendimiento sin que haya un crash, lo que hace que la falla sea fácil de pasar por alto.

Lo que realmente rompe “pasta térmica por todas partes”

Modo de fallo 1: Mayor resistencia térmica por TIM grueso

Demasiada pasta crea una capa más gruesa. La resistencia térmica aumenta. Las temperaturas suben más rápido bajo carga y se estabilizan a un equilibrio más alto. Verás rampas
de ventilador antes, throttling antes y menor tiempo en turbo. En producción, eso se traduce en tiempos de ejecución más largos de trabajos, más latencia en las colas y, a veces,
resets por watchdog en sistemas con límites térmicos estrictos.

Modo de fallo 2: Mal contacto por montaje desigual

El exceso de pasta puede hacer hidroplaneo del disipador durante la instalación, especialmente si aprietas una esquina demasiado y temprano. El disipador puede atrapar una cuña
de pasta y no sentarse completamente. A menudo verás uno o dos núcleos o un CCD más caliente que el resto, no un aumento uniforme. Ese patrón importa: grita “problema de contacto”
más que “problema de flujo de aire.”

Modo de fallo 3: Pasta en lugares equivocados

Pasta untada en los bordes del socket, componentes SMD o entre pines es un regalo que sigue dando. Incluso los compuestos “no conductores” pueden causar caminos de fuga cuando se mezclan
con polvo. También complica inspecciones posteriores: no puedes distinguir fácilmente si un componente está agrietado, quemado o simplemente lleva un abrigo gris de moda.

Modo de fallo 4: Pasta incorrecta para el perfil operativo

Desktops y servidores viven vidas diferentes. Un servidor puede tener carga sostenida, altas temperaturas de entrada y ciclos térmicos constantes. Algunas pastas de consumo se secan,
separan o hacen pump-out más rápido bajo ese régimen. A la inversa, algunos compuestos de alto rendimiento son quisquillosos y exigen montaje y preparación perfectos.

Modo de fallo 5: Perseguir la pasta cuando el problema real es el flujo de aire

La clásica mala diagnóstico: “La CPU está caliente, por lo tanto la pasta está mala.” En un rack, la temperatura de entrada, paneles de llenado faltantes, paquetes de cables, salud de los ventiladores y curvas BMC
suelen ser el verdadero villano. La pasta es lo más fácil de tocar, así que se la echa la culpa. Mientras tanto el servidor está respirando el escape del vecino porque alguien quitó un panel y nadie quiso abrir un ticket.

Broma #2: Si tu aplicación de pasta parece arte moderno, la CPU responderá con arte performativo—principalmente throttling interpretativo.

Guion de diagnóstico rápido

Cuando una máquina corre caliente después de un repaste—or empieza a throttlear durante cargas normales—no empieces por repastear otra vez. Empieza por aislar el cuello de botella en tres pasadas:
(1) confirma sensores y síntomas, (2) correlaciona con comportamiento de potencia y frecuencia, (3) valida flujo de aire y contacto mecánico. Estás respondiendo una pregunta rápidamente:
¿el factor limitante es generación de calor, transferencia de calor o eliminación de calor?

Primero: confirma que el síntoma es real y específico

• Revisa la temperatura del paquete de la CPU, los deltas por núcleo/CCD y si el BMC coincide con el SO.
• Busca flags de throttling térmico y caídas de frecuencia bajo carga.
• Compáralo con un host “hermano” conocido bueno si tienes uno.

Segundo: correlaciona térmicas con la carga y la potencia

• ¿Se activa con la carga (solo durante AVX o compresión), por tiempo (después de 20 minutos) o por ambiente (solo en picos del pasillo caliente)?
• ¿Las ventiladores suben al máximo? Si las RPM son bajas mientras la CPU está caliente, sospecha control de ventiladores/políticas BMC.
• ¿Estás limitado por potencia (clamp de potencia del paquete) en lugar de por térmica?

Tercero: valida flujo de aire y contacto mecánico

• Flujo de aire: temperaturas de entrada, RPM de chasis, filtros bloqueados, blanks faltantes, obstrucciones por cables.
• Mecánico: patrón de torque del disipador, separadores de montaje, alineación de placa trasera, placa fría deformada, espaciador correcto para el socket.
• TIM: cantidad correcta, sin vacíos, sin contaminación, tipo correcto para el rango de temperaturas.

Si sigues este orden, evitas el error más caro: hacer retrabajos físicos repetidos sin un cambio en la medición, lo que convierte un problema técnico en un incidente de fiabilidad con tiempo de inactividad extra.

Tareas prácticas: comandos, salidas y decisiones

Estos son comandos reales que puedes ejecutar en servidores Linux típicos para determinar si tu problema es throttling, sensores, flujo de aire o contacto. Cada tarea incluye
qué significa la salida y qué decidir después. Úsalos como usarías iostat para almacenamiento: como evidencia, no adorno.

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

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

Significado: Dos núcleos están ~17–18°C más calientes que otros en condiciones similares. Eso no es “flujo de aire del chasis”; suele ser contacto desigual o un punto caliente localizado.

Decisión: Pasa a comprobaciones de throttling y luego a una inspección mecánica si el patrón persiste bajo una carga controlada.

Task 2: Watch temperatures and fan behavior live

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

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

Significado: Los ventiladores están altos; el sistema está intentando. Las temperaturas siguen siendo elevadas, con un gran delta. La eliminación de calor funciona; la transferencia de calor (TIM/contacto) es sospechosa.

Decisión: Valida flags de throttling; prepárate para una recolocación con torque y cantidad de pasta correctos.

Task 3: Confirm CPU frequency and throttling during load

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

Significado: Si estás bajo carga y ves ~1.2 GHz en una CPU que debería estar mucho más alta, probablemente estás en throttling o limitado por potencia.

Decisión: Revisa los logs del kernel por eventos de throttling térmico y compáralos con límites de potencia.

Task 4: Look for thermal throttling messages in kernel logs

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

Significado: Esto es throttling térmico explícito. No “tal vez.” No “el usuario dice que va lento.”

Decisión: Determina si se debe a flujo de aire/ambiente o a una mala interfaz/montaje comprobando la entrada de aire y el control de ventiladores a continuación.

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

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

Significado: La entrada está razonable; las temperaturas de CPU son altas; los ventiladores están altos y saludables. Esto apunta alejándose de problemas de pasillo caliente y hacia contacto del disipador/TIM.

Decisión: Programa una ventana de mantenimiento para recolocar; no pierdas tiempo reconfigurando curvas de ventilador.

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

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

Significado: No estás ejecutando “powersave.” Bien. Si fuera “powersave,” podrías interpretar erróneamente relojes bajos como throttling térmico.

Decisión: Procede a comprobaciones de límite de potencia/térmico en lugar de ajustar la política de CPU.

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

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

Significado: Esto muestra consumo real; no prueba que estés limitado, pero da contexto. Si tu plataforma aplica un cap estricto, los relojes pueden bajar incluso a temperaturas seguras.

Decisión: Si las temperaturas son altas y los relojes bajos, es térmico. Si las temperaturas son moderadas y los relojes bajos, sospecha cap de potencia o límites de BIOS.

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

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

Significado: Una sola carga (compresión/crypto/AVX-intensiva) puede empujar las térmicas más que tus pruebas habituales.

Decisión: Usa una prueba de carga repetible (el mismo binario) al validar una recolocación; si no, perseguirás ruido.

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

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

Significado: Ahora tienes una herramienta consistente para generar carga.

Decisión: Ejecuta un estrés corto y observa temperaturas; no lo hagas en producción sin ventana de mantenimiento y límites de seguridad.

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

Significado: Una carga repetible de 60 segundos permite comparaciones antes/después. Combínalo con watch sensors.

Decisión: Si el throttling ocurre rápido, es probablemente contacto/TIM. Si tarda mucho, sospecha flujo de aire, filtros obstruidos o ambiente.

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

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

Significado: El calor puede exacerbar componentes marginales. Un repaste que aumenta temperaturas puede convertir “errores corregibles raros” en “incidente.”

Decisión: Trata problemas térmicos como riesgos de fiabilidad; planifica remediación antes de que los errores dejen de ser corregibles.

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

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

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

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

Significado: Durante el throttling, la CPU puede convertirse en cuello de botella e inflar los tiempos de procesamiento de peticiones, lo que puede parecer que “el almacenamiento se pone lento.”

Decisión: Si la latencia de almacenamiento sube mientras los relojes de CPU bajan y las temperaturas suben, corrige la térmica antes de afinar I/O.

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

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

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

Significado: El resilver de discos exige mucho a CPU y memoria (checksums, compresión, paridad). Si tus térmicas de CPU son marginales, este tipo de carga lo encontrará.

Decisión: Si estás en throttling, considera pausar o programar cargas pesadas de mantenimiento hasta corregir la refrigeración—si no, prolongas el periodo de riesgo.

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

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

Significado: El BMC vio un cruce de umbral térmico. También un error de procesador puede indicar inestabilidad bajo calor.

Decisión: Escala. La térmica no es cosmética; ahora está causando fallos a nivel de hardware.

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

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

Significado: Algunas plataformas ajustan el comportamiento de ventiladores según sensores de intrusión o tapa. Si está activado, el control de ventiladores puede actuar de forma extraña.

Decisión: Si la intrusión está afirmada o “open”, arregla el estado físico primero; no ajustes el software para esquivar una tapa faltante.

Tres microhistorias corporativas desde el campo

1) El incidente causado por una suposición errónea

Una empresa SaaS mediana tenía una flota de servidores de base de datos estable durante años. Luego ocurrió una actualización de hardware rutinaria: misma familia de CPU, stepping ligeramente más nuevo,
nueva revisión del soporte del disipador por parte del proveedor. Nada alarmante. Un técnico repasteó un puñado de hosts durante el rack-and-stack porque algunos disipadores parecían
“un poco secos.” Eso pareció responsable.

La suposición errónea fue simple: más pasta mejora la térmica, y “se va a expandir sola.” El técnico usó una cantidad generosa e hizo una instalación rápida—apretó una esquina,
luego la opuesta, pero no en pasos incrementales. Las máquinas arrancaron. Las temperaturas parecían aceptables en idle. Todos se fueron a casa.

Al día siguiente, el clúster de base de datos empezó a mostrar picos impredecibles de latencia. No masivos. Lo justo para disparar reintentos, que generaron más carga, que generaron
más calor. Bajo el trabajo de analítica nocturna, dos nodos empezaron a throttlear, quedaron retrasados en la replicación y el gestor de clúster los expulsó por “lentos y no saludables.”
El failover funcionó, pero fue desordenado: un bache de disponibilidad, alarmas, y una larga reunión de causa raíz.

El postmortem fue menos sobre pasta y más sobre disciplina. Compararon telemetría térmica entre nodos “repasteados” y “sin tocar” y encontraron una firma clara:
temperaturas de paquete más altas bajo carga y un delta por núcleo mayor. La solución no fue heroica. Sacaron las máquinas en una ventana de mantenimiento, limpiaron correctamente,
aplicaron una cantidad medida, apretaron en patrón cruzado con torque consistente y validaron con una prueba de estrés antes de devolverlas al pool.

La lección real: asumir que un cambio físico es benigno porque el sistema arranca es como asumir que un cambio de almacenamiento es seguro porque el sistema de archivos se monta. Arrancar no es
un benchmark. Es un saludo.

2) La optimización que salió mal

Otra organización—grande, ahorradora y orgullosa de su “eficiencia”—quería reducir ruido de ventiladores y consumo en un laboratorio que se había convertido en área de staging de producción. Alguien decidió
“optimizar” la térmica: reaplicar pasta de alta conductividad premium en la flota y luego reducir curvas de ventilador ligeramente vía BMC. El argumento: mejor pasta = ventiladores más lentos.

La pasta estaba bien. El proceso no. Usaron un método de extensión para crear una capa con aspecto perfecto, pero no controlaron el espesor. Algunos disipadores terminaron con una capa demasiado gruesa.
Las máquinas corrieron más frías en idle—porque todo corre más frío en idle—y el cambio de curva hizo que el ambiente pareciera más silencioso y “estable.” Diapositiva de victoria.

Luego ejecutaron pruebas de carga de staging más realistas que las sintéticas anteriores. Bajo cargas sostenidas intensivas en CPU, las temperaturas subieron lentamente, los ventiladores subieron tarde
(por la nueva curva) y las CPUs empezaron a bajar relojes. Los resultados de rendimiento fueron peores. El equipo asumió que la nueva pasta necesitaba “rodaje,” porque ese es el tipo de mito al que te aferras
cuando ya has comprometido la narrativa.

Al final, la optimización falló dos veces: el cambio de curva redujo margen térmico y el espesor inconsistente del TIM aumentó la resistencia térmica. Revirtieron la política de ventiladores, estandarizaron
el método de aplicación y solo entonces la “pasta premium” produjo una mejora medible. El coste fue principalmente tiempo y credibilidad, que en la vida corporativa no se renueva fácilmente.

La regla operativa: nunca agrupes cambios físicos con cambios de política a menos que estés preparado para bisecarlos. Si no puedes bisecar, no puedes aprender.

3) La práctica aburrida pero correcta que salvó el día

Un equipo de almacenamiento con nodos densos de cómputo y NVMe tenía un hábito que parecía casi cómico: cada vez que se quitaba un disipador, lo registraban como un swap de disco.
Ticket, motivo, tipo de pasta, método, patrón de torque y una instantánea de prueba de estrés de 60 segundos antes/después. A nadie le encantaba hacerlo. A todos les encantaba tenerlo después.

Durante un freeze de cambios de fin de trimestre, un nodo empezó a throttlear de forma intermitente. No fallaba por completo. Simplemente iba lento. El servicio que alojaba tenía SLOs estrictos de cola alta,
y ese nodo estaba lastrando a todo el pool. Por el freeze, el equipo necesitaba pruebas antes de solicitar una excepción para trabajo físico.

Sacaron los datos históricos del host y vieron que las temperaturas de paquete bajo la prueba estándar habían aumentado ~10°C desde el último mantenimiento. También vieron que el host tenía
un registro de retirada de disipador dos meses antes por un RMA de placa. Eso les dio una hipótesis plausible: un problema sutil de asiento o pump-out.

Obtuvieron la excepción, recolocaron el disipador usando su procedimiento estándar, y la prueba posterior coincidió con la línea base. Sin drama, sin conjeturas, sin “prueba otra marca de pasta.”
El host volvió al pool y el fin de trimestre pasó sin incidentes de rendimiento.

Así es como se ve lo aburrido cuando funciona: un pequeño ritual de medición y documentación que convierte un misterio térmico en una tarea de mantenimiento predecible.

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

1) Altas temperaturas de CPU inmediatamente después del repaste

Síntomas: Las temperaturas están peor que antes; los ventiladores suben rápido; throttling con carga modesta.

Causa raíz: Demasiada pasta (capa gruesa), bolsas de aire atrapadas, disipador no asentado plano.

Solución: Quita el disipador, limpia ambas superficies completamente, aplica una cantidad medida pequeña, recoloca apretando en patrón cruzado incremental. Valida con una prueba de carga repetible.

2) Un núcleo/CCD mucho más caliente que los demás

Síntomas: Gran delta por núcleo bajo carga; la temperatura del paquete parece “más o menos” pero el punto caliente alcanza umbrales.

Causa raíz: Presión de montaje desigual, inclinación, separador/espaciador incorrecto, base del disipador deformada, cuña de pasta.

Solución: Revisa compatibilidad del hardware de montaje; recoloca; asegura torque uniforme. Considera inspeccionar el patrón de contacto (impresión de pasta fina) para confirmar cobertura completa.

3) Temperaturas bien en idle, mal después de 20–60 minutos

Síntomas: Subida gradual y luego throttling; a menudo correlaciona con cargas sostenidas (scrubs, rebuilds, trabajos por lotes).

Causa raíz: Restricción de flujo de aire (filtros, paquetes de cables), curva de ventilador demasiado conservadora, picos de temperatura ambiente/entrada, pump-out de la pasta con el tiempo.

Solución: Revisa temperatura de entrada y RPM de ventiladores vía BMC; inspecciona la ruta de flujo de aire; restaura la política de ventilador del proveedor; si el historial lo sugiere, recoloca con una pasta conocida por resistir pump-out.

4) El sistema se reinicia bajo carga, las térmicas “parecen normales”

Síntomas: Reinicios aleatorios; a veces no hay log térmico claro; eventos MCE/EDAC ocasionales.

Causa raíz: Punto caliente localizado no captado por el sensor que observas, sobrecalentamiento de VRM, desalineación del disipador o falta de tapa/ducting que hace que componentes se calienten.

Solución: Usa sensores BMC más allá de la CPU (VRM, placa base, entrada). Confirma ductos y shrouds instalados. Revisa el asiento del disipador. No ignores los errores corregidos.

5) Ventiladores atascados bajos mientras las temperaturas suben

Síntomas: La CPU alcanza 90°C y los ventiladores permanecen a baja RPM; sin fallos obvios de ventilador.

Causa raíz: Configuración incorrecta de la política de ventiladores en BMC, sensor de intrusión del chasis afirmado o bug de firmware.

Solución: Compara temperaturas del SO con lecturas del BMC; revisa SEL para eventos de política; restaura el perfil térmico por defecto; actualiza firmware de BMC en una ventana controlada.

6) Pasta en el socket/componentes después del retrabajo

Síntomas: Contaminación visual; problemas de arranque intermitentes; inestabilidad inexplicable post-mantenimiento.

Causa raíz: Aplicación excesiva y esparcido durante la extracción/instalación del disipador; método de limpieza deficiente.

Solución: Apaga, desensambla con cuidado, limpia con disolvente apropiado y herramientas sin pelusa, inspecciona con luz brillante. Si se usó pasta conductora, trátalo como incidente y considera reemplazo de placa.

7) “Hicimos repaste y sigue caliente”

Síntomas: Sin mejora tras múltiples repastes; todos están cansados; el sistema sigue marginal.

Causa raíz: El problema no es la pasta: disipador equivocado, shroud faltante, hardware de montaje incorrecto, ventilador degradado, aletas de disipador obstruidas o temperatura de entrada alta.

Solución: Deja de repastear. Valida números de pieza, shrouds y flujo de aire. Verifica ventiladores y limpieza de aletas. Compáralo con un host conocido bueno en el mismo rack.

Listas de verificación / plan paso a paso

Paso a paso: el procedimiento de repaste “hacerlo una vez y hasta luego” (grado servidor)

1. Planifica la validación. Elige una prueba de carga repetible (p. ej., stress-ng --cpu N --timeout 60s) y registra temperaturas y frecuencias de referencia antes de tocar el hardware.
2. Programa una ventana. Necesitas tiempo para limpiar con cuidado y una prueba de estrés posterior. Apresurarse es cómo la pasta se convierte en estilo de vida.
3. Apaga y descarga. Quita cables de alimentación, espera, sigue la guía de servicio de la plataforma. No cambies en caliente tu paciencia.
4. Retira el disipador con cuidado. Afloja en patrón cruzado poco a poco. Evita girar que esparza la pasta sobre componentes.
5. Limpia ambas superficies completamente. Usa toallitas/palitos sin pelusa y disolvente apropiado. Elimina la pasta vieja de bordes y esquinas donde le encanta esconderse.
6. Inspecciona las superficies. Busca arañazos, picaduras, residuos y señales de contacto desigual. Confirma el soporte/separadores correctos para el socket.
7. Aplica pasta con moderación. Usa el mínimo que rellene huecos: punto pequeño para IHS típico, línea/X para IHS rectangulares grandes de servidor según corresponda.
8. Asienta el disipador recto hacia abajo. Evita deslizarlo; un pequeño desplazamiento puede crear vacíos o empujar la pasta desigual.
9. Apreta incrementalmente en patrón cruzado. Pocas vueltas por tornillo, alternando esquinas, hasta asentar según especificación del proveedor.
10. Reinstala shrouds y ductos. No son estética opcional. Son la diferencia entre “sistema de refrigeración” y “esperanza.”
11. Arranca y verifica sensores. Confirma ventiladores, temperatura de entrada y temperaturas de CPU tanto en OS como en BMC.
12. Ejecuta la carga de validación. Compara con la línea base. Si las temperaturas empeoran, detente y revisa montaje y cantidad de pasta en lugar de “probar un patrón nuevo” al azar.
13. Registra el cambio. Anota tipo de pasta, método y métricas antes/después. Tu yo futuro te lo agradecerá desagradablemente.

Lista de verificación: saneamiento de flujo de aire y chasis (antes de culpar a la pasta)

• Todos los módulos de ventilador presentes, modelo correcto, sin fallos reportados.
• Aletas del disipador limpias; sin enmallado de polvo ni espuma de embalaje (sí, pasa).
• Shroud de aire instalado y bien asentado.
• Paneles de llenado instalados; sin huecos RU abiertos que cortocircuiten el flujo de aire.
• Paquetes de cables sin bloquear entradas de ventilador o el shroud de CPU.
• Temperaturas de entrada dentro del rango esperado; compara con vecinos del rack.
• Perfil térmico BMC en modo recomendado por el proveedor para tu carga de trabajo.

Lista de verificación: elegir pasta como un adulto

• Prefiere pasta no conductora y no capacitiva para servidores de flota a menos que tengas razón sólida y controles de mano de obra.
• Prioriza estabilidad frente a ciclos térmicos (resistencia al pump-out) sobre reclamaciones de conductividad pico en benchmarks.
• Estandariza en uno o dos compuestos aprobados y un método de aplicación por plataforma.
• Evita mezclar pastas o aplicar sobre residuos; limpia hasta superficie desnuda cada vez.
• Si usas pads de cambio de fase por diseño, no los reemplaces por pasta a la ligera; estás alterando un proceso de ensamblaje validado.

Preguntas frecuentes

1) ¿Demasiada pasta térmica puede empeorar realmente las temperaturas?

Sí. La pasta es principalmente un relleno de huecos de aire. Una capa gruesa aumenta la resistencia térmica comparada con contacto metal-metal, elevando temperaturas y acelerando throttling.

2) ¿Cómo sé si apliqué demasiado sin desmontar?

Busca una firma post-repaste: temperaturas de paquete más altas bajo la misma carga controlada, mayores deltas por núcleo, rampas de ventilador antes y nuevos eventos de throttling en logs.
Esos patrones sugieren fuertemente una mala interfaz o un problema de asiento.

3) ¿El método del “guisante” siempre es correcto?

No. Es un buen valor predeterminado para muchos tamaños de IHS generalistas, pero huellas IHS rectangulares grandes en servidores suelen beneficiarse de una línea o X para asegurar cobertura de bordes.
El requisito real es cobertura fina y continua después del montaje, no lealtad a una forma.

4) ¿Debo esparcir la pasta con una tarjeta/espátula?

En operaciones de flota, esparcir a menudo aumenta la variabilidad en el espesor e introduce burbujas si se hace a la ligera. Un punto/linea/X controlado con presión de montaje correcta suele ser más consistente.
Si vas a esparcir, necesitas un método que controle el espesor y evite aire.

5) ¿Con qué frecuencia deberían repastearse los servidores?

Menos frecuentemente de lo que sugieren foros de hobby. Muchas ensamblajes de grado servidor funcionan años sin repaste. Repastea cuando tengas evidencia: temperaturas subiendo con el tiempo,
después de quitar el disipador o tras un problema de contacto verificado—no como ritual estacional.

6) ¿Valen la pena los compuestos “metálicos” o “metal líquido” en producción?

Normalmente no, a menos que tengas un proceso controlado y la plataforma lo soporte. TIM conductor aumenta riesgos: cortocircuitos, corrosión y retrabajo más difícil.
La fiabilidad gana por varios grados.

7) Mi CPU está caliente; ¿eso significa automáticamente que la pasta está mal?

No automáticamente. Revisa temperaturas de entrada, RPM de ventiladores, shrouds y política BMC primero. Los problemas de flujo de aire son comunes y afectan múltiples componentes, no solo el paquete de CPU.

8) ¿Por qué veo throttling pero no una alarma de temperatura obvia?

El throttling puede activarse por puntos calientes localizados o sensores internos que no mapean claramente a la temperatura que estás mirando. Además, el firmware puede throttlear
de forma proactiva por debajo de umbrales “críticos”. Usa tanto logs del OS como sensores BMC para tener una imagen más completa.

9) ¿Cuál es el factor mecánico más importante además de la cantidad de pasta?

La presión y la uniformidad del montaje. Una pasta perfecta no puede compensar un disipador inclinado, con torque desigual o con espaciador/placa trasera incorrectos.

10) Si repasteo y las temperaturas mejoran, ¿ya está todo hecho?

Has terminado cuando validas bajo una carga sostenida representativa y registras el resultado. Muchos problemas térmicos aparecen con el tiempo, no en el primer minuto.

Conclusión: próximos pasos que sí puedes hacer

La pasta térmica no es magia ni un proyecto artesanal. Es una interfaz controlada en un sistema de transferencia de calor con modos de fallo conocidos: demasiado gruesa, asiento desigual,
material incorrecto o culpar al TIM por pecados de flujo de aire. Los repastes más desordenados vienen de la misma causa raíz que los cortes de servicio desordenados: cambiar cosas sin medir.

Pasos prácticos siguientes:

• Elige una carga de validación estándar y registra térmicas y frecuencias de referencia por plataforma.
• Cuando las térmicas dériven, ejecuta el guion de diagnóstico rápido antes de tocar hardware.
• Si debes repastear, estandariza tipo de pasta, método de aplicación y secuencia de torque—y documenta como cualquier otro cambio en producción.
• Tras el retrabajo, valida bajo carga sostenida realista, no solo “arranca”.
• Trata regresiones térmicas como riesgos de fiabilidad, especialmente en nodos de almacenamiento que hacen rebuilds y scrubs.

Si recuerdas una cosa: la cantidad correcta de pasta es la mínima que hace al aire irrelevante. Todo lo que vaya más allá es solo decoración sobre un problema de calor.