La pared térmica: cómo la física acabó con la historia favorita del marketing

La historia que se rompió: GHz como plan de negocio

Durante mucho tiempo, la industria del hardware vendió una promesa simple: espera seis meses, compra la siguiente CPU y tu software será más rápido.
Esa historia fue genial para compras y terrible para la disciplina de ingeniería. Fomentó una pereza específica: no arregles el algoritmo, no reduzcas
los viajes de ida y vuelta, no agrupes, no particiones con cuidado; deja que la “Ley de Moore” te lleve.

El problema es que la Ley de Moore (cantidad de transistores) nunca garantizó la frecuencia de reloj. Y ni siquiera la cantidad de transistores es el titular
que la gente cree. La realidad operativa está limitada por la entrega de potencia, la refrigeración y la rapidez con la que puedes mover datos hacia donde
ocurre el cómputo. Puedes empaquetar muchos transistores en un dado pequeño; no puedes empaquetar un flujo de calor infinito en un disipador. La física
no negocia. Las finanzas sí, pero la física gana.

Así que la industria pivotó: más núcleos, vectores más anchos, cachés más profundas, aceleradores especializados y comportamiento turbo agresivo que
es esencialmente una negociación en chip entre temperatura, potencia y tiempo. Aún obtienes mejoras de rendimiento, pero no las obtienes
automáticamente. Debes ganarlas con paralelismo, localidad y afinamiento según la carga de trabajo.

Aquí está la traducción operativa: si no puedes explicar por qué tu servicio es rápido, no podrás mantenerlo rápido.
“Actualizamos el tipo de instancia” no es una estrategia de rendimiento; es una medicación temporal con efectos secundarios.

Qué es (y qué no es) la pared térmica

La pared térmica es el límite práctico donde aumentar la frecuencia y la actividad de conmutación empuja la disipación de potencia más allá de lo que
puedes remover —dentro de las restricciones de costo, tamaño, fiabilidad y ruido. Más allá de ese punto, los relojes más altos no son “difíciles”,
son caros: obligan a mayor voltaje, lo que dispara la potencia dinámica, lo que eleva la temperatura, lo que aumenta la fuga, lo que
eleva la temperatura otra vez. Aquí es donde la gráfica deja de parecer una línea recta y empieza a parecer una etiqueta de advertencia.

La pared térmica no significa “las CPUs empeoraron”. Las CPUs se volvieron más complicadas. Ocultan latencia con cachés, ejecución fuera de orden,
predicción de saltos, ejecución especulativa y —cuando las cosas van bien— turbo. Pero en última instancia están constreñidas por:

• Potencia: cuántos vatios puede suministrar el paquete y la plataforma sin activar límites.
• Eliminación de calor: qué tan rápido puedes trasladar el calor del silicio al aire ambiente (o al agua) sin freír nada.
• Energía por trabajo útil: especulación desperdiciada, fallos de caché y pipelines bloqueados consumen energía sin aportarte trabajo útil.
• Movimiento de datos: la latencia de memoria y E/S puede convertir una “CPU rápida” en un camarero caro.

La pared no es un solo precipicio. Es un paquete de techos. Tu carga encuentra uno distinto dependiendo de si está limitada por CPU,
por memoria, por saltos de predicción, si favorece vectores, si es intensiva en E/S o simplemente está desplegada en un chasis con flujo
de aire diseñado por alguien que odia ventiladores.

Una idea parafraseada relevante de Gene Kranz (director de vuelo de Apollo) es: El fracaso no es una opción (idea parafraseada).
En términos SRE: no puedes fingir que las termias no son reales solo porque tu alerting no incluya temperatura.

La física que no puedes subcontratar

Conceptos básicos de potencia: por qué el voltaje es el villano

Un modelo simplificado para la potencia dinámica de la CPU es: P ≈ C × V² × f, donde C es la capacitancia efectiva de conmutación,
V es el voltaje y f es la frecuencia. Puedes discutir los detalles, pero la implicación es estable:
los aumentos de frecuencia tienden a requerir aumentos de voltaje, y los aumentos de voltaje perjudican el doble.

Por eso murió el “simplemente aumenta los relojes”. Pasar de 3.5 GHz a 4.5 GHz rara vez es un coste lineal. Es un impuesto de potencia y térmico
que aparece como:

• Mayor potencia del paquete y estrés en los VRM
• Troteo (throttling) más agresivo
• Rendimiento menos predecible bajo carga sostenida
• Mayor coste de refrigeración (y más fallos de ventiladores, y más quejas por ruido)

Transferencia de calor: el cuello de botella menos glamuroso

El calor debe viajar desde los transistores a través del silicio, a través de un spreader térmico, a través del material de interfaz térmica, hacia un
disipador, hacia el aire y fuera del chasis. Cada paso tiene resistencia. Puedes mejorarlo, pero no infinitamente y no de forma barata.

En un data center también tienes restricciones a nivel de sala: temperatura de entrada, contención de pasillo caliente, capacidad de CRAC, gestión de flujo
de aire y el hecho de que “este rack está bien” no es lo mismo que “este servidor en el medio del rack está bien”.

Fuga: cuando el calor crea más calor

A medida que los transistores se reducen, las corrientes de fuga importan más. La fuga aumenta con la temperatura. Así que mayor temperatura provoca
más fuga, lo que incrementa la potencia, lo que incrementa la temperatura. Este es el bucle que ves cuando una CPU parece estable por un minuto y luego
se desliza hacia un estado de throttling tras el soak térmico.

El secreto sucio: utilización no es rendimiento

Un núcleo al 60% de utilización todavía puede ser el cuello de botella si pasa tiempo esperando memoria o compitiendo por locks. Mientras tanto,
una pila de almacenamiento puede estar “bien” en throughput y, aun así, arruinar la latencia de cola. La pared térmica impulsó arquitecturas hacia
rendimiento oportunista: ráfagas cortas de alta frecuencia (turbo) y muchos núcleos paralelos. Eso hace que interpretar métricas sea más difícil,
no más fácil.

No es una sola pared: térmica, potencia, memoria y la “pared de cables lentos”

La pared de potencia: límites de plataforma que no se van por arte de magia

Incluso si tu CPU pudiera funcionar a mayor potencia, la plataforma puede no hacerlo. Los VRM de la placa, la capacidad de la PSU y los presupuestos de
potencia del rack limitan lo posible. Las instancias en la nube ocultan esto, pero no lo eliminan: tu “vecino ruidoso” a veces es la plataforma haciendo
cumplir su propia política de potencia.

La pared de memoria: los núcleos se hicieron más rápidos; la memoria no tanto

El rendimiento de cómputo de la CPU creció más rápido de lo que mejoró la latencia de DRAM. Puedes añadir canales y ancho de banda, pero la latencia no
baja como la gente espera. Si tu carga falla mucho en caché, más GHz no ayuda mucho: tu CPU está esperando la memoria.

Por eso las cachés crecieron en tamaño y por qué la localidad se volvió la forma adulta de obtener rendimiento. También es por eso que “simplemente añade
núcleos” puede volverse contraproducente: más núcleos comparten ancho de banda de memoria y caché de último nivel. En cierto punto, estás añadiendo
más comensales a la misma cocina.

La pared de interconexión/retraso en los cables: la distancia importa también en el dado

Los transistores se hicieron pequeños, pero los cables no se volvieron mágicamente instantáneos. La propagación de la señal, la complejidad de ruteo y la
distribución del reloj se convierten en límites. Los diseños monolíticos grandes y de alta frecuencia son dolorosos de sincronizar y alimentar.

La pared de I/O: almacenamiento y red pueden ser tu fuente de calor oculta

Las cargas intensivas en E/S no son “gratis” porque no sean CPU. Provocan interrupciones, cambios de contexto, trabajo del kernel, cifrado,
checksums y copias de memoria. Eso quema potencia y calienta CPUs mientras tu app técnicamente “espera”.

Los ingenieros de almacenamiento ven esto constantemente: la latencia sube, la potencia del paquete CPU aumenta, el turbo se vuelve menos estable y de
repente tu “servicio limitado por CPU” es en realidad limitado por colas.

Hechos e historia que explican el giro

• Las velocidades de reloj se estabilizaron en los años mediados de 2000 para CPUs mainstream; los proveedores cambiaron a escalado multinúcleo en lugar de aumentos interminables de GHz.
• El “escalado de Dennard” se desaceleró: la vieja suposición de que reducir transistores disminuiría la potencia por área se rompió, haciendo de la densidad de potencia la limitación principal.
• La era NetBurst de Intel enfatizó altas frecuencias y pipelines profundos; la industria luego favoreció diseños con mejor rendimiento por vatio.
• Turbo boost se volvió mainstream: las CPUs exceden la frecuencia base oportunísticamente cuando existe margen térmico/potencia, haciendo el rendimiento sostenido menos determinista.
• Las cachés de último nivel crecieron enormemente porque los fallos de caché se volvieron demasiado caros en relación con el rendimiento del núcleo.
• Se proliferaron extensiones SIMD/vectoriales (SSE, AVX, etc.) como forma de obtener más trabajo por ciclo—con el coste de picos de potencia y reducciones de frecuencia bajo uso intensivo vectorial.
• Los data centers comenzaron a preocuparse por el PUE como métrica de negocio, reflejando que remover calor es un coste operativo real, no una ocurrencia tardía.
• Los aceleradores especializados crecieron (GPUs, DPUs, ASICs) porque los núcleos de propósito general no pueden hacer todo eficientemente a escala dentro de presupuestos de potencia.

Cómo aparece la pared térmica en producción

En producción rara vez ves un gran cartel “PARED TÉRMICA”. Ves síntomas indirectos:

• La latencia empeora bajo carga sostenida, incluso si la utilización de la CPU no se dispara.
• El rendimiento difiere entre hosts idénticos porque el flujo de aire, el polvo, las curvas de ventilador o el firmware difieren.
• Los trabajos nocturnos funcionan bien en invierno y “misteriosamente” se ralentizan en verano.
• Los benchmarks lucen bien por 30 segundos; las cargas reales corren horas y alcanzan heat soak.
• Añadir núcleos mejora el throughput pero empeora la latencia de cola debido a la contención de memoria y efectos de planificación.
• Un rack está bien; un servidor no lo está. Los puntos calientes son localizados y crueles.

Cuando te topas con la pared, la forma de la falla importa. Algunas cargas se degradan de forma gradual; otras caen en picado porque son sensibles a la latencia
(contención de locks, pausas de garbage collection, colas de almacenamiento, deadlines RPC).

Broma #1: Marketing ama los números “hasta”; porque “hasta” no cabe en una diapositiva. Tu pager, desafortunadamente, lee la letra pequeña.

Guion de diagnóstico rápido

La forma más rápida de perder un día es discutir “CPU vs almacenamiento” sin evidencia. Haz esto en su lugar. El objetivo es identificar el limitador dominante
en 10–20 minutos y elegir la siguiente medición, no perfeccionar tu teoría.

Primero: confirma si estás siendo estrangulado o limitado

• Revisa frecuencias actuales y máximas, estado de turbo y contadores de throttling.
• Revisa límites de potencia del paquete y si los estás alcanzando (comportamiento PL1/PL2).
• Revisa temperaturas y comportamiento de ventiladores; busca heat soak.

Segundo: separa “ocupado” de “bloqueado”

• Mira la presión de la cola de ejecución y los cambios de contexto.
• Revisa indicadores de stalls de memoria (fallos de caché, ciclos estancados) con herramientas de muestreo.
• Revisa contención de locks y tiempo de kernel vs tiempo de usuario.

Tercero: revisa colas de E/S y latencia, no solo throughput

• Almacenamiento: await por dispositivo, utilización y profundidad de cola.
• Red: retransmisiones, pérdidas y carga softirq.
• Sistema de ficheros: presión de páginas sucias, writeback y actividad de swap.

Cuarto: verifica topología y política

• Colocación NUMA, afinidad de IRQ, gobernador de CPU y límites de cgroup.
• Virtualización o restricciones de gestión de potencia en la nube.
• Diferencias de firmware (microcode, ajustes BIOS).

Tareas prácticas: comandos, salida y la decisión que tomas

Estos son los movimientos que haces cuando las gráficas son vagas y la caída es real. Cada tarea incluye: un comando, qué significa la salida
y qué decisión sigue. Ejecútalos en un host representativo bajo carga, no en un canario inactivo.

Task 1: See if CPUs are throttling due to temperature

cr0x@server:~$ sudo dmesg -T | egrep -i 'thrott|thermal|PROCHOT' | tail -n 5
[Mon Jan  8 02:11:41 2026] CPU0: Core temperature above threshold, cpu clock throttled (total events = 17)
[Mon Jan  8 02:11:41 2026] CPU2: Core temperature above threshold, cpu clock throttled (total events = 17)
[Mon Jan  8 02:11:42 2026] CPU0: Package temperature above threshold, cpu clock throttled (total events = 9)

Significado: El kernel te está diciendo que la CPU alcanzó umbrales térmicos y redujo la frecuencia.
Decisión: Deja de debatir el software primero. Verifica la refrigeración, flujo de aire, curvas de ventilador y ajustes de potencia sostenida; luego
vuelve a ejecutar pruebas de carga tras abordar los temas térmicos.

Task 2: Read live frequencies and throttling counters (Intel)

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 5 --num_iterations 2
  Avg_MHz  Busy%  Bzy_MHz  TSC_MHz  CoreTmp  PkgTmp  PkgWatt  CorWatt  GFXWatt
    2870   62.14    4618     2600     92.0    95.0    188.4    142.7     0.0
    2555   63.02    4050     2600     96.0    99.0    205.1    153.2     0.0

Significado: Alto Busy% con Avg_MHz en descenso y temperaturas en aumento sugiere presión térmica sostenida; la potencia es alta y sube.
Decisión: Si este host está en un rack caliente, arregla el flujo de aire primero. Si ocurre en todas partes, considera límites de potencia,
perfiles de ventilador o remodelado de la carga (reducir intensidad vectorial, agrupar E/S).

Task 3: Check CPU frequency policy and governor

cr0x@server:~$ sudo cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 5200 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 1200 MHz (asserted by call to hardware)

Significado: Estás en powersave; bajo algunas cargas puede no subir rápido o puede estar constreñido por la política de la plataforma.
Decisión: Para servicios sensibles a la latencia, establece performance (o ajusta EPP) y mide potencia/temperaturas después. No hagas esto a ciegas en un chasis con restricciones térmicas.

Task 4: Detect cgroup CPU caps masquerading as “thermal issues”

cr0x@server:~$ systemctl show --property=CPUQuota --property=CPUAccounting myservice.service
CPUAccounting=yes
CPUQuota=200%

Significado: El servicio está capado a ~2 núcleos de tiempo CPU. Puede parecer que “la CPU no está saturada” mientras las peticiones se encolan.
Decisión: Aumenta la cuota o escala horizontalmente. Si estás limitado por potencia, los topes pueden ser intencionales—entonces necesitas trabajo de eficiencia, no deseos.

Task 5: Check run queue pressure and load vs cores

cr0x@server:~$ uptime
 02:14:10 up 41 days,  6:22,  2 users,  load average: 48.12, 44.90, 38.77

Significado: Un promedio de carga cercano o por encima del recuento de hilos de CPU sugiere backlog ejecutable o I/O wait contribuyendo.
Decisión: Usa vmstat y pidstat a continuación para separar ejecutable vs bloqueado e identificar procesos ofensores.

Task 6: Identify CPU saturation vs I/O wait quickly

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
18  2      0 128432  64220 912340    0    0   120   980 8210 9920 42 14 33 11  0
22  5      0 121100  64180 905220    0    0    80  2100 9020 11020 38 12 29 21  0

Significado: Un wa no trivial (I/O wait) con procesos bloqueados (b) indica retrasos en almacenamiento o sistema de ficheros.
Decisión: Pasa a iostat y latencia por disco; no micro-optimices código mientras el kernel espera la cola de un dispositivo.

Task 7: Measure per-device latency and saturation

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   r_await w_await aqu-sz  %util
nvme0n1         120.0   980.0     1.20   18.40   7.90   96.5
nvme1n1         110.0   910.0     1.10   17.90   7.40   94.8

Significado: Alto w_await, alto aqu-sz y ~95% de %util indica que los dispositivos están saturados y las escrituras se encolan.
Decisión: Reduce la amplificación de escritura (agrupar, comprimir, ajustar fs/zfs), añade dispositivos o mueve escrituras calientes a otro lado. Si esto son “solo logs”, trata los logs como tráfico de producción.

Task 8: Check filesystem writeback pressure (dirty throttling)

cr0x@server:~$ grep -E 'Dirty:|Writeback:' /proc/meminfo
Dirty:            184532 kB
Writeback:         81244 kB

Significado: Memoria sucia/writeback elevada sugiere que el kernel está empujando escrituras y puede limitar a los escritores.
Decisión: Si tu app es sensible a la latencia, considera aislar cargas intensivas en escritura, ajustar ratios dirty o usar pipelines async/buffered con backpressure.

Task 9: Detect swap activity (often a “memory wall” costume)

cr0x@server:~$ sar -W 1 3
Linux 6.5.0 (server) 	01/08/2026 	_x86_64_	(64 CPU)

02:15:01 AM  pswpin/s pswpout/s
02:15:02 AM      0.00     18.00
02:15:03 AM      0.00     22.00

Significado: Actividad de swap-out significa que estás expulsando páginas; la latencia puede explotar incluso si la CPU parece “bien”.
Decisión: Arregla la presión de memoria primero: reduce el working set, ajusta cachés (app, JVM, ARC) o añade RAM. No “optimices CPU” mientras hay paging.

Task 10: Check NUMA placement and remote memory hits

cr0x@server:~$ numastat -p 12345
Per-node process memory usage (in MBs) for PID 12345 (myservice)
                           Node 0          Node 1           Total
                  --------------- --------------- ---------------
Private                  18240.32         1024.11        19264.43
Heap                      6144.00          512.00         6656.00
Stack                        64.00           64.00          128.00
Huge                         0.00            0.00            0.00

Significado: La mayor parte de la memoria está en el Nodo 0; si los hilos corren en Nodo 1 pagarás latencia remota. Esto es la pared de memoria en la vida diaria.
Decisión: Fija CPU y memoria vía numactl, corrige afinidad o reconfigura tu scheduler. Los bugs NUMA son bugs de rendimiento con gabardina de “aleatoriedad”.

Task 11: Find top CPU consumers and whether they burn sys time

cr0x@server:~$ pidstat -u -p ALL 1 2 | head -n 12
02:16:10 AM   UID       PID    %usr %system  %CPU  Command
02:16:11 AM     0       842     1.00    12.00 13.00  ksoftirqd/12
02:16:11 AM  1001    12345    48.00     6.00 54.00  myservice
02:16:11 AM     0      2101     0.00     7.00  7.00  nvme_poll_wq

Significado: %system significativo y ksoftirqd pueden indicar presión de interrupciones (red/almacenamiento) en lugar de cómputo puro.
Decisión: Revisa distribución de IRQ, ajustes NIC/RSS, polling de almacenamiento y rutas de código con muchas syscalls. A veces el “problema de CPU” es que estás haciendo trabajo del kernel.

Task 12: Inspect IRQ affinity and imbalance (hot CPU cores)

cr0x@server:~$ cat /proc/interrupts | head -n 8
           CPU0       CPU1       CPU2       CPU3
  24:   9182736        120        110         98   PCI-MSI 524288-edge      eth0-TxRx-0
  25:       220   8122331        140        115   PCI-MSI 524289-edge      eth0-TxRx-1
  26:       210        160   7341120        130   PCI-MSI 524290-edge      eth0-TxRx-2

Significado: Las interrupciones están distribuidas entre CPUs, pero si ves una CPU recibiendo casi todo obtienes cores calientes y throttling sin alta utilización promedio.
Decisión: Arregla afinidad (irqbalance o manual), valida colas RSS y evita fijar todas las IRQ al mismo nodo NUMA que tus hilos más calientes a menos que quieras hacerlo a propósito.

Task 13: Spot memory bandwidth saturation and cache miss pain (quick sample)

cr0x@server:~$ sudo perf stat -e cycles,instructions,cache-misses,LLC-load-misses -p 12345 -- sleep 10
 Performance counter stats for process id '12345':

     18,220,114,992      cycles
     10,002,332,110      instructions              #    0.55  insn per cycle
        82,110,442      cache-misses
        40,220,119      LLC-load-misses

      10.001201545 seconds time elapsed

Significado: IPC bajo (instrucciones por ciclo) más muchos fallos de LLC sugiere que la CPU está estancada en memoria. Esto es la pared de memoria, operativamente.
Decisión: Mejora localidad (diseño de datos, estrategia de caché), reduce pointer chasing, agrupa peticiones o mueve datos calientes a niveles más rápidos. Comprar núcleos más rápidos no ayudará mucho.

Task 14: Check ZFS ARC pressure if you run ZFS (storage meets memory wall)

cr0x@server:~$ sudo arc_summary | egrep -i 'ARC Size|ARC Target|Cache Hit Ratio' | head -n 6
ARC Size:                               32.0 GiB
ARC Target Size (Adaptive):             48.0 GiB
Cache Hit Ratio:                        71.2 %

Significado: Tamaño de ARC por debajo del objetivo y una ratio de aciertos mediocre puede significar que estás constreñido por memoria; las lecturas pueden golpear disco más a menudo, elevando latencia y sobrecarga de CPU.
Decisión: Asigna más RAM, ajusta límites de ARC o rediseña el working set. No prive al ARC para “ahorrar memoria” y luego te preguntes por qué los discos están ocupados.

Task 15: Validate actual temperatures and fan control at the hardware level

cr0x@server:~$ sudo ipmitool sdr type Temperature | head -n 6
Inlet Temp       | 26 degrees C      | ok
CPU1 Temp        | 92 degrees C      | ok
CPU2 Temp        | 94 degrees C      | ok
Exhaust Temp     | 48 degrees C      | ok

Significado: La entrada está razonable, las CPUs están calientes, el escape es alto. Eso apunta a contacto de disipador, curva de ventilador, filtros obstruidos o flujo insuficiente a través del chasis.
Decisión: Inspecciona la ruta física: polvo, fallos de ventiladores, obstrucciones por cables. Si es un patrón de flota, revisa la distribución de racks y las temperaturas de entrada.

Task 16: Confirm power limits and package power reporting

cr0x@server:~$ sudo rdmsr -a 0x610 | head -n 2
00000000d0a8d0a8
00000000d0a8d0a8

Significado: Este MSR codifica límites de potencia del paquete (PL1/PL2) en muchos sistemas Intel; el hex crudo necesita decodificación, pero la consistencia entre CPUs sugiere un tope impuesto por la plataforma.
Decisión: Si el rendimiento está limitado, revisa ajustes BIOS/firmware y herramientas del proveedor. En la nube, acéptalo y optimiza para perf/watt en lugar de perseguir GHz fantasma.

Broma #2: Intenté overclockear un servidor una vez. Funcionó hasta que las leyes de la termodinámica presentaron un ticket.

Tres mini-historias corporativas desde la pared

Mini-historia 1: El incidente causado por una suposición incorrecta (benchmarks de ráfaga ≠ realidad sostenida)

Una empresa SaaS de tamaño medio migró una API sensible a latencia a instancias optimizadas para cómputo más nuevas. El benchmark del proveedor se veía genial.
Su prueba interna también se veía bien—porque corría cinco minutos y declaró victoria.

En producción, la API manejó una oleada al mediodía y luego se degradó lentamente durante la siguiente hora. El p99 se fue elevando. Los reintentos amplificaron el tráfico.
El autoscaler añadió nodos, pero los nuevos nodos se degradaron de la misma manera, solo con más coste total.

La suposición equivocada: “Si la CPU está al 50–60%, no estamos limitados por CPU.” En realidad, la potencia sostenida del paquete empujó las CPUs a una
frecuencia estrangulada en estado estable. Su servicio estaba “medio utilizado” porque pasaba tiempo bloqueado en memoria y E/S del kernel, mientras el comportamiento
turbo cambiaba minuto a minuto. La métrica de utilización era honesta; el modelo mental no.

La solución fue aburrida: extendieron las pruebas de carga a al menos una hora, graficaron frecuencia a lo largo del tiempo e incorporaron contadores térmicos y de potencia
en sus dashboards de rendimiento. También ajustaron el batching de peticiones y redujeron las asignaciones por petición, bajando la presión de fallos de caché.
Terminaron con mejor p99 y menor consumo, el tipo de resultado que nadie pone en una diapositiva pero que todos quieren a las 02:13.

Mini-historia 2: La optimización que salió mal (vectorización frente a límites de potencia)

Un equipo de pipeline de datos optimizó un bucle caliente habilitando instrucciones vectoriales más agresivas en las flags de compilación. En un host único,
el throughput aumentó. El ingeniero que lo hizo merecía crédito—a nivel local.

En producción, el efecto a nivel de flota fue distinto. Bajo carga sostenida intensiva en vectores, las CPUs redujeron frecuencia para mantenerse dentro de los límites
de potencia y térmicos. El código “más rápido” aumentó el consumo instantáneo de potencia, lo que activó reducciones de frecuencia, lo que redujo rendimiento en otros hilos,
incluyendo compresión y manejo de red.

El síntoma fue extraño: el throughput de extremo a extremo a veces mejoró, a veces empeoró, y la latencia de cola para servicios no relacionados en nodos compartidos se vio afectada.
El equipo de plataforma vio más eventos térmicos y un aumento en las RPM de ventiladores. El equipo de datos vio KPIs ruidosos y culpó a la red. Todos estaban medio en lo cierto y totalmente molestos.

La resolución fue aislar la carga en nodos con mejor refrigeración y limitar la intensidad vectorial para cargas mixtas. También añadieron telemetría de potencia por nodo a
las decisiones de scheduling. La optimización no era “mala”, era dependiente del contexto, y el contexto era limitado por potencia. La física no se preocupa por tus flags del compilador.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día (planificación de capacidad con potencia y térmicas)

Una firma de servicios financieros ejecutaba un clúster privado con SLOs estrictos de latencia. También tenía un proceso de cambios estricto que a nadie le encantaba:
líneas base de firmware, ajustes BIOS de potencia consistentes y auditorías térmicas trimestrales que incluían abrir chasis y limpiar filtros.

Durante una ola de calor, varios centros de datos vecinos reportaron problemas de rendimiento y throttling sorpresa. Esta firma también tuvo problemas—RPM de ventilador algo más altas,
temperaturas de entrada algo más elevadas—pero sin impacto al cliente. Sus sistemas se mantuvieron dentro del margen.

La diferencia no fue heroica. Fue que su modelo de capacidad incluyó márgenes de potencia y refrigeración, no solo núcleos de CPU y RAM.
Trataron “vatios por rack” como un recurso de primera clase y mantuvieron suficiente cabeza térmica para que el comportamiento turbo no fuera una apuesta.

El postmortem se leyó como una lista de verificación, no como un thriller. Ese es el punto. Los sistemas más fiables rara vez son emocionantes; son simplemente
mantenidos de forma implacable, casi ofensivamente, bien.

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

1) Síntoma: la latencia sube durante 30–90 minutos de carga

Causa raíz: Heat soak conduce a throttling sostenido; el turbo se ve bien al principio, mal después.

Solución: Ejecuta pruebas de carga más largas, monitoriza frecuencias y temperaturas, mejora flujo de aire/refrigeración y considera límites de potencia que mantengan el rendimiento estable.

2) Síntoma: “La CPU está solo al 50%” pero las colas explotan

Causa raíz: Los hilos están bloqueados en memoria (IPC bajo) o bloqueados en E/S; la utilización no es throughput.

Solución: Usa perf stat para indicadores de stalls, iostat para await de dispositivos y elimina contención (batching, localidad, reducir asignaciones).

3) Síntoma: dos hosts idénticos tienen rendimiento distinto

Causa raíz: Diferencias de firmware, fallos de ventilador, polvo, diferentes temperaturas de entrada o distintos límites de potencia.

Solución: Hacer cumplir bases BIOS/microcode; auditar sensores IPMI; inspeccionar y limpiar físicamente; validar flujo de aire en racks.

4) Síntoma: después de una “optimización”, la potencia sube y el throughput cae

Causa raíz: Mayor actividad de conmutación (vectorización, polling ocupado, hilos extra) dispara límites de potencia o térmicos, reduciendo la frecuencia.

Solución: Mide potencia del paquete y frecuencia bajo carga sostenida; considera capar hilos, reducir ancho vectorial o aislar cargas en nodos apropiados.

5) Síntoma: el almacenamiento parece “rápido” en throughput pero p99 es terrible

Causa raíz: Encolamiento y amplificación de escritura; el dispositivo está saturado (%util alto) y la latencia se dispara.

Solución: Concéntrate en await/aqu-sz, reduce escrituras pequeñas aleatorias, añade dispositivos o cambia la ruta de escritura (batch, LSM, async).

6) Síntoma: micropicos aleatorios de latencia sin pico claro de CPU

Causa raíz: Tormentas de interrupciones, saturación de softirq o desbalance del scheduler causando cores calientes.

Solución: Revisa /proc/interrupts, ajusta afinidad de IRQ/RSS, considera isolcpus para dispositivos ruidosos y verifica comportamiento de ksoftirqd.

7) Síntoma: añadir núcleos mejora throughput pero empeora latencia de cola

Causa raíz: Ancho de banda de memoria compartido y contención de LLC; más hilos aumentan la interferencia.

Solución: Limita hilos, colocación NUMA consciente, reduce datos calientes compartidos y usa límites de concurrencia en lugar de paralelismo ilimitado.

8) Síntoma: instancias cloud del mismo tipo se comportan de forma inconsistente

Causa raíz: Gestión de potencia a nivel host, diferentes silicios/steppings subyacentes o contención de potencia por vecino ruidoso.

Solución: Fija a hosts dedicados donde sea necesario, mide frecuencia sostenida por instancia y diseña SLOs asumiendo variabilidad.

Listas de verificación / plan paso a paso

Cuando el rendimiento cae tras una actualización de hardware

1. Comportamiento sostenido base: ejecuta una prueba de carga de 60–120 minutos; registra frecuencia, temperatura y potencia del paquete a lo largo del tiempo.
2. Verifica la política: gobernador/EPP de CPU, ajustes turbo, perfil de potencia BIOS y cuotas de cgroup.
3. Revisa térmicas físicamente: temperaturas de entrada/salida, RPM de ventiladores, polvo, obstrucción por cables, asiento del disipador.
4. Revisa comportamiento de memoria: IPC, fallos de LLC, actividad de swap, localidad NUMA.
5. Revisa colas de I/O: await y utilización por dispositivo, writeback del sistema de ficheros, retransmisiones de red.
6. Re-prueba: cambia solo una variable mayor a la vez; de lo contrario “arreglarás” por coincidencia.

Cuando sospechas throttling térmico en una flota

1. Elige tres hosts: mejor, medio, peor.
2. Recopila: turbostat (o equivalente), temperaturas ipmitool, eventos térmicos en dmesg.
3. Compara: Avg_MHz sostenida bajo la misma carga; busca diferencias de temperatura y topes de potencia.
4. Actúa: si está localizado, arregla flujo de aire y mantenimiento de hardware; si es sistémico, revisa límites de potencia y ubicación de cargas.

Cuando necesitas latencia predecible (no solo velocidad pico)

1. Prioriza estabilidad sobre pico: afina para frecuencia consistente en lugar de ganancias puntuales de turbo.
2. Establece límites de concurrencia: no permitas solicitudes paralelas ilimitadas que creen contención de memoria y E/S.
3. Minimiza fallos de caché: reduce asignaciones, mejora localidad, evita caminos calientes con punteros pesados.
4. Haz la E/S aburrida: agrupa escrituras, usa backpressure y mantén cortas las colas de dispositivos.
5. Instrumenta térmicas: trata la temperatura y los eventos de throttling como señales de producción.

Preguntas frecuentes

1) ¿La pared térmica es la razón por la que el rendimiento por hilo dejó de mejorar?

En gran medida, sí. Los relojes más altos requieren potencia (voltaje) desproporcionada y generan densidad de calor insostenible. Los proveedores dirigieron las ganancias hacia multinúcleo, caché y especialización.

2) ¿Por qué los benchmarks muestran gran rendimiento pero producción es más lenta?

Muchos benchmarks son cortos y se ejecutan antes del heat soak. Producción es sostenida, con cargas mixtas y sensible a throttling, stalls de memoria y encolamiento de E/S. Mide a lo largo del tiempo.

3) Si mi CPU no está al 100%, ¿puede aún ser el cuello de botella?

Absolutamente. Puedes estar limitado por latencia de memoria, locks o E/S mientras la utilización de CPU parece moderada. Mira IPC, fallos de caché, cola de ejecución y await de dispositivos.

4) ¿“Más núcleos” siempre ayuda?

No. Más núcleos pueden aumentar contención por ancho de banda de memoria y caché de último nivel, y pueden incrementar potencia/calor, provocando throttling. Escala núcleos según localidad y ancho de banda de la carga.

5) ¿Cuál es la diferencia entre throttling térmico y limitación de potencia?

El throttling térmico reacciona a umbrales de temperatura; la limitación de potencia hace cumplir límites de vatios del paquete/plataforma (a menudo PL1/PL2). Ambas reducen frecuencia; la solución depende de cuál tocaste.

6) ¿Cómo cambian las cosas los modos turbo?

Turbo hace el rendimiento oportunista. Puedes obtener alta frecuencia brevemente, pero el rendimiento sostenido depende de refrigeración y margen de potencia. Trata la “frecuencia base” como el número honesto.

7) ¿Pueden problemas de almacenamiento causar calor y throttling en la CPU?

Sí. Altas tasas de E/S pueden generar interrupciones, CPU del kernel, cifrado/checksums y copias de memoria. Eso quema potencia mientras tu app “espera” y puede desestabilizar el comportamiento turbo.

8) ¿Qué debo monitorizar para detectar la pared térmica temprano?

Como mínimo: frecuencia sostenida por host, eventos de throttling térmico, potencia del paquete, temperaturas de entrada/salida y latencia/profundidad de cola por dispositivo. Añádelos junto a p95/p99 de latencia.

9) ¿Es la refrigeración líquida la solución?

Es una herramienta, no una cura. La refrigeración líquida puede aumentar el margen y la densidad, pero tu carga aún puede alcanzar límites de potencia, paredes de memoria o contención de E/S. Aún necesitas eficiencia.

10) ¿Cuál es la solución más rentable en un entorno limitado por potencia?

Reduce trabajo desperdiciado: mejora localidad, disminuye asignaciones, agrupa E/S, limita concurrencia y elimina contención de locks. El rendimiento por vatio es el nuevo “GHz”.

Conclusión: qué hacer la próxima semana, no la próxima década

La pared térmica no mató el progreso. Mató la fantasía de que el progreso es automático. Tus sistemas siguen acelerando, pero solo si
alineas el software con las restricciones: vatios, calor, latencia de memoria y encolamiento de E/S. La historia de marketing era “la velocidad es gratis”.
La verdad operativa es “la velocidad se diseña”.

Pasos prácticos:

• Añade frecuencia sostenida, temperatura y eventos de throttling a tus dashboards estándar por host.
• Extiende las pruebas de rendimiento para incluir heat soak. Si dura menos de 30 minutos, es una demo, no una prueba.
• Construye un hábito: cuando la latencia sube, revisa throttling y colas antes de tocar el código.
• Para trabajo de throughput, optimiza por rendimiento por vatio: localidad, batching, menos stalls, menos viajes al kernel.
• Haz las bases de la flota aburridas: ajustes BIOS consistentes, microcode, curvas de ventilador y mantenimiento físico.

No le ganas a la física. La presupuestas, la instrumentas y diseñas alrededor de ella. Eso no es pesimismo. Eso es producción.