Debian 13: el estrangulamiento térmico arruina el rendimiento — demuestra y arregla refrigeración/límites de potencia

enero 16, 2026 • febrero 3, 2026 • Lectura: 31 min • Views: 6

¿Te fue útil?

Nada hace que un ingeniero de almacenamiento se ponga nervioso como un benchmark que empieza fuerte y luego se desploma lentamente hasta la mediocridad. Tu conjunto NVMe parecía heroico durante 30 segundos, luego las escrituras se convierten en una llovizna suave. Los gráficos parecen un acantilado de playa: meseta alta, luego una triste caída.

En Debian 13, esto a menudo no es “Debian lento”. Son física, firmware y políticas de potencia. El estrangulamiento térmico (CPU, NVMe, HBA, chipset) reduce silenciosamente la frecuencia, la velocidad del enlace o la profundidad de colas, y tu rendimiento cae con ello. El truco es demostrarlo de forma clara y luego arreglarlo sin cocinar el hardware ni disparar los interruptores.

Guía rápida de diagnóstico

Si estás de guardia y el equipo de almacenamiento mira un gráfico de rendimiento inestable, no tienes tiempo para bailes interpretativos. Necesitas una secuencia que encuentre el cuello de botella rápido.

Primero: confirma que depende del tiempo y está correlacionado con la temperatura

Ejecuta una carga sostenida (fio o la reejecución de tu carga real) durante al menos 5–10 minutos. Al estrangulamiento le encanta el “después del calentamiento”.
Observa la frecuencia de la CPU + indicadores de throttling y la temperatura NVMe al mismo tiempo. Si el rendimiento cae mientras las temperaturas suben y se activan límites, tienes un caso.

Segundo: identifica qué componente se estrangula

CPU throttle: la frecuencia baja, eventos de límite de potencia (PL1/PL2), temperatura alta del paquete, los contadores de “throttled” aumentan.
NVMe throttle: la temperatura del controlador sube, cambia el estado de “thermal management”, aparecen avisos SMART, picos de latencia.
PCIe/estado de enlace: el enlace del dispositivo se reentrena, aumentan contadores de errores, la anchura/velocidad negociada baja con el calor.
Control de refrigeración: los ventiladores no aumentan, el BMC está atascado en modo “acústico”, el firmware del portátil se niega a acelerarlos.

Tercero: decide si es política o física

Política: gobernador powersave, límites de potencia demasiado bajos, presets BIOS “eficiente energéticamente”, perfiles de plataforma.
Física: polvo, admisión bloqueada, disipadores NVMe faltantes, pasta térmica mala, ventilador muerto, mapeo de zonas de ventilador equivocado.

Haz esos tres pasos y dejarás de discutir “Debian vs kernel vs sistema de archivos” y empezarás a discutir sobre la cosa que realmente se está calentando, lo cual es progreso.

Cómo se ve el estrangulamiento en el rendimiento real

El estrangulamiento térmico no es sutil. Simplemente parece sutil si solo mides una cosa.

Patrón clásico:

fio comienza, por ejemplo, a 6–7 GB/s en lecturas sobre un conjunto NVMe en stripe.
Después de 60–180 segundos, el rendimiento se desliza hasta 3–4 GB/s.
La latencia crece. Las profundidades de cola dejan de ayudar.
La frecuencia de la CPU baja unos cientos de MHz, o la temperatura del controlador NVMe cruza un umbral, o ambos.

Luego detienes la prueba, el sistema se enfría y la siguiente prueba “misteriosamente” se ve bien otra vez. Por eso el estrangulamiento sobrevive tanto en producción: los benchmarks cortos y las reproducciones rápidas no lo detectan.

Una cita que vale la pena recordar: Werner Vogels, CTO de Amazon: “Todo falla, todo el tiempo.” (idea parafraseada). El estrangulamiento es un modo de fallo que parece una regresión de rendimiento hasta que lo instrumentas como un problema de fiabilidad.

Datos y contexto interesantes (porque la historia se repite)

Intel introdujo comportamientos de turbo agresivos hace años, y “rápido a corto plazo, más lento a largo plazo” se volvió normal: boosts PL2, sostenimiento PL1.
Los discos NVMe tienen estados formales de gestión térmica (a menudo dos niveles), y muchas unidades de consumo están configuradas para estrangularse pronto con pobre flujo de aire.
Los centros de datos solían diseñarse alrededor de discos giratorios; la densidad NVMe aumentó el calor por unidad de rack dramáticamente y las suposiciones de flujo de aire fallaron.
El escalado de frecuencia en Linux ha tenido múltiples eras (acpi-cpufreq, intel_pstate, amd_pstate), y los valores por defecto han cambiado con el tiempo; “funcionaba en Debian X” no es evidencia.
Los límites de potencia RAPL fueron diseñados para control energético y pueden exponerse a través de MSRs; los vendedores a veces establecen valores conservadores para cumplir objetivos acústicos o térmicos de la plataforma.
Algunos BIOS de servidores intercambian rendimiento sostenido por ruido; “Balanced” a menudo significa “silencioso hasta que duele”.
Las tasas de error PCIe pueden aumentar con la temperatura; la señalización marginal empeora al calentar, y el reentrenamiento del enlace puede reducir el ancho de banda efectivo.
La degradación de la pasta térmica es real; la pasta se desplaza con ciclos de calor a lo largo de años, aumentando la temperatura de unión con la misma carga.
Los portátiles fueron pioneros en heurísticas de estrangulamiento agresivas (temperatura de piel, protección de batería), y esas ideas filtraron a servidores de pequeño factor y dispositivos edge.

Demostrarlo: instrumentación que aguanta en un postmortem

“Está estrangulando” no es una afirmación; es un conjunto de contadores, temperaturas y evidencia en series temporales. Tu objetivo es una única línea temporal donde:

La carga se mantiene constante.
El rendimiento se degrada.
Un estado de límite térmico/potencia cambia al mismo tiempo.

Así es como ganas discusiones con proveedores, con tu propio equipo y con la parte de tu cerebro que quiere que el problema sea “un ajuste”.

Además: no recolectes todo. Recolecta las cosas correctas. Para CPU: frecuencia, temperatura del paquete, contadores de throttling, límites de potencia. Para NVMe: temperatura del controlador y eventos térmicos. Para la refrigeración de la plataforma: RPM de ventiladores y sensores de temperatura. Para almacenamiento: distribuciones de latencia, no solo rendimiento.

Broma #1: El estrangulamiento térmico es tu servidor diciendo educadamente: “Estoy cansado”, justo antes de empezar a hacer la mitad del trabajo por el mismo salario.

Tareas prácticas: comandos, salidas y decisiones

Estas son tareas de grado producción. Cada una incluye: comando, salida de ejemplo, lo que significa y la decisión que tomas. Ejecútalas durante una carga sostenida, no en reposo. Cuando sea posible, usa dos terminales: uno para la carga y otro para la telemetría.

Tarea 1: Confirma kernel y básicos de la plataforma

cr0x@server:~$ uname -a
Linux server 6.12.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.0-1 (2025-10-01) x86_64 GNU/Linux

Lo que significa: Estás en la línea de kernel de Debian 13 y la versión específica está registrada. El comportamiento de throttling puede cambiar con controladores cpufreq y ajustes del scheduler.

Decisión: Guarda esta cadena en las notas del incidente. Si más tarde ajustas BIOS o firmware, querrás controlar variables.

Tarea 2: Revisa el gobernador y driver de CPU (comprobación de política)

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

Lo que significa: intel_pstate + powersave puede estar bien para muchas cargas, pero es sospechoso cuando el rendimiento cae bajo carga sostenida.

Decisión: Si diagnosticas una regresión de rendimiento, fuerza temporalmente performance para eliminar la política como variable (más adelante arreglaremos de forma sostenible).

Tarea 3: Forzar gobernador de CPU a performance (prueba temporal)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Lo que significa: Has eliminado una fuente común de “caída misteriosa”.

Decisión: Repite la misma carga y observa si la caída persiste. Si desaparece, acabas de encontrar un problema de política (o escondiste un problema térmico al terminar más rápido—sigue leyendo).

Tarea 4: Instalar y usar turbostat para captar throttling de CPU

cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y linux-cpupower linux-tools-common linux-tools-amd64
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  linux-cpupower linux-tools-amd64 linux-tools-common

cr0x@server:~$ sudo turbostat --Summary --interval 2
Summary: 2.00 sec samples
  PkgTmp  Bzy_MHz  Avg_MHz  Busy%  IRQ     SMI  PkgWatt  CorWatt  GFXWatt
   93     2800     2200     84.0   12000     0   150.2    120.8     0.0

Lo que significa: La temperatura del paquete es alta (93C). Si ves colapso de frecuencia mientras Busy% se mantiene alto, eso es clásico límite térmico/potencia. En algunas plataformas turbostat también puede mostrar contadores “Throt” o razones de límite.

Decisión: Si la temperatura del paquete se aproxima a TJmax de la plataforma y el rendimiento cae, la refrigeración o los límites de potencia están en juego. Siguiente paso: correlaciona con rendimiento y límites de potencia.

Tarea 5: Demostrar limitación de potencia vía contadores RAPL (Intel)

cr0x@server:~$ sudo apt-get install -y msr-tools
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  msr-tools

cr0x@server:~$ sudo modprobe msr

cr0x@server:~$ sudo rdmsr -a 0x610
00000000dd8080c8
00000000dd8080c8
00000000dd8080c8
00000000dd8080c8

Lo que significa: MSR 0x610 suele ser PKG_POWER_LIMIT. Necesitas decodificar para interpretar vatios/ventanas de tiempo; el valor bruto es evidencia y puede decodificarse con herramientas/scripts si lo estandarizas internamente.

Decisión: Si tu organización no está decodificando límites RAPL, hazlo. Si los límites son inesperadamente bajos frente a la clase TDP del CPU, sospecha del perfil BIOS o de topes del proveedor.

Tarea 6: Revisar estado amd_pstate (sistemas AMD)

cr0x@server:~$ cat /sys/devices/system/cpu/amd_pstate/status
active

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

Lo que significa: amd_pstate activo, pero el gobernador es powersave. Puede estar bien; también puede ser demasiado conservador bajo cargas sostenidas de I/O + compresión + checksum.

Decisión: Para diagnóstico, cambia a performance y compara resultados sostenidos. Si mejora, aplica una política persistente (sección posterior).

Tarea 7: Vigila temperaturas en vivo (simple y eficaz)

cr0x@server:~$ sudo apt-get install -y lm-sensors
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  lm-sensors

cr0x@server:~$ sudo sensors-detect --auto
# sensors-detect revision 3.6.0
# System: ExampleVendor ServerBoard
# Summary: 3 drivers loaded

cr0x@server:~$ watch -n 2 sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +92.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +88.0°C  (high = +90.0°C, crit = +100.0°C)

nvme-pci-0100
Adapter: PCI adapter
Composite:    +78.9°C  (low  = -20.1°C, high = +84.8°C)

Lo que significa: La CPU está por encima de “high”, NVMe se acerca a “high”. Ese es el escenario para estrangulamiento dual: la CPU reduce cómputo, NVMe reduce su propia velocidad y la latencia se vuelve fea.

Decisión: Si las temperaturas se acercan a “high” durante I/O sostenido, trata la refrigeración como cuello de botella primario, no como un pensamiento posterior.

Tarea 8: Inspeccionar temperaturas SMART y eventos térmicos NVMe

cr0x@server:~$ sudo apt-get install -y nvme-cli smartmontools
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  nvme-cli smartmontools

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 80 C
available_spare                     : 100%
percentage_used                     : 2%
thermal_management_t1_trans_count    : 7
thermal_management_t2_trans_count    : 1
time_for_thermal_management_t1       : 438
time_for_thermal_management_t2       : 55

Lo que significa: La unidad entró en estado de gestión térmica T1 e incluso T2. Eso es estrangulamiento con papeleo.

Decisión: Si estos contadores aumentan durante la ventana de caída de rendimiento, deja de culpar al sistema de archivos. Arregla el flujo de aire y la disipación alrededor de los dispositivos NVMe.

Tarea 9: Revisar sensores de temperatura NVMe vía smartctl (vista alternativa)

cr0x@server:~$ sudo smartctl -a /dev/nvme0
smartctl 7.4 2024-12-08 r5560 [x86_64-linux-6.12.0-1-amd64] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       ExampleNVMe 3.84TB
Firmware Version:                   2B0QEXM7
=== START OF SMART DATA SECTION ===
Temperature:                        80 Celsius
Temperature Sensor 1:               82 Celsius
Temperature Sensor 2:               76 Celsius
Warning  Comp. Temperature Time:    438
Critical Comp. Temperature Time:    55

Lo que significa: Los contadores de tiempo en temperatura de advertencia y crítica no son cero y están aumentando. Eso correlaciona fuertemente con throttling y a veces con aceleración del desgaste del medio.

Decisión: Trata la temperatura NVMe como tratas errores de memoria: una señal de fiabilidad, no solo “rendimiento”.

Tarea 10: Verificar velocidad/anchura negociada PCIe (el calor puede exponer marginalidad)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | sed -n '/LnkCap:/,/LnkSta:/p'
LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (downgraded), Width x4 (ok)

Lo que significa: El enlace es capaz de 16GT/s pero actualmente está a 8GT/s. Eso puede pasar por ajustes del BIOS, integridad de señal, o a veces recuperación de errores después de calentamiento.

Decisión: Si ves un enlace degradado durante la fase “lenta”, investiga errores PCIe e instalación física (riser, cable, slot, flujo de aire). Arreglar eso puede duplicar el ancho de banda al instante.

Tarea 11: Buscar errores PCIe que coincidan con calor y throttling

cr0x@server:~$ sudo dmesg -T | egrep -i 'aer|pcie|nvme|thrott'
[Mon Dec 29 11:04:12 2025] pcieport 0000:00:1d.0: AER: Corrected error received: 0000:01:00.0
[Mon Dec 29 11:04:12 2025] nvme 0000:01:00.0: AER: can't recover (no error_detected callback)
[Mon Dec 29 11:05:01 2025] nvme nvme0: I/O 123 QID 4 timeout, aborting

Lo que significa: Incluso los errores PCIe corregidos pueden causar problemas de rendimiento; los timeouts son peores. El calor puede hacer que enlaces al límite se comporten mal.

Decisión: Si los errores aumentan durante carga sostenida y las temperaturas son altas, aborda flujo de aire/sloting/cableado y actualiza firmware. No “tunes” alrededor de un enlace inestable.

Tarea 12: Medir rendimiento y latencia de modo que detecte throttling (serie temporal con fio)

cr0x@server:~$ sudo apt-get install -y fio
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  fio

cr0x@server:~$ fio --name=warmth --filename=/dev/nvme0n1 --direct=1 --ioengine=io_uring --rw=read --bs=128k --iodepth=32 --numjobs=1 --runtime=600 --time_based=1 --group_reporting=1 --status-interval=10
warmth: (groupid=0, jobs=1): err= 0: pid=22114: Mon Dec 29 11:07:10 2025
  read: IOPS=52.1k, BW=6512MiB/s (6827MB/s)(63.6GiB/10s)
...
warmth: (groupid=0, jobs=1): err= 0: pid=22114: Mon Dec 29 11:09:20 2025
  read: IOPS=34.0k, BW=4250MiB/s (4457MB/s)(41.5GiB/10s)
...
warmth: (groupid=0, jobs=1): err= 0: pid=22114: Mon Dec 29 11:17:10 2025
  read: IOPS=33.2k, BW=4149MiB/s (4350MB/s)(40.5GiB/10s)

Lo que significa: Mismo trabajo, mismos parámetros, el rendimiento bajó y se mantuvo bajo. Eso es limitación sostenida, no ruido aleatorio.

Decisión: Cuando veas un descenso escalonado, correlaciona inmediatamente las marcas de tiempo con turbostat/sensors/nvme smart-log. Si la correlación es fuerte, deja de cambiar banderas de fio. Empieza a arreglar refrigeración/potencia.

Tarea 13: Observa estadísticas de la capa de bloques y la cola del dispositivo (¿se está atascando el dispositivo?)

cr0x@server:~$ iostat -dxm 2 5 nvme0n1
Linux 6.12.0-1-amd64 (server) 	12/29/2025 	_x86_64_	(64 CPU)

Device            r/s     rMB/s   rrqm/s  %rrqm r_await rareq-sz  aqu-sz  %util
nvme0n1        52000.0   6500.0     0.0   0.00    0.60    128.0   31.0  99.0
nvme0n1        34000.0   4250.0     0.0   0.00    0.95    128.0   32.0  99.0

Lo que significa: %util permanece alto mientras el rendimiento baja y await sube. El dispositivo es el limitador (o el camino hacia él), no la CPU que le quita solicitudes.

Decisión: Apunta tu linterna a la temperatura NVMe, estado del enlace PCIe y la refrigeración física.

Tarea 14: Revisa el journal de systemd en busca de pistas térmicas/potencia

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'thermal|thrott|powercap|rapl|cpu frequency' | tail -n 20
Dec 29 11:04:55 server kernel: intel_rapl_common: Found RAPL domain package
Dec 29 11:05:03 server kernel: CPU0: Core temperature above threshold, cpu clock throttled
Dec 29 11:05:03 server kernel: CPU2: Core temperature above threshold, cpu clock throttled

Lo que significa: El kernel literalmente te está diciendo que aplicó throttling. Créelo.

Decisión: Toma esto como confirmación y luego arregla causas raíz: flujo de aire, disipadores, control de ventiladores o perfil de potencia.

Tarea 15: En servidores, revisa sensores IPMI y comportamiento de ventiladores

cr0x@server:~$ sudo apt-get install -y ipmitool
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  ipmitool

cr0x@server:~$ sudo ipmitool sensor | egrep -i 'fan|temp|inlet|exhaust|cpu'
Inlet Temp       | 29.000     | degrees C  | ok
Exhaust Temp     | 51.000     | degrees C  | ok
CPU1 Temp        | 92.000     | degrees C  | ok
FAN1             | 1800.000   | RPM        | ok
FAN2             | 1700.000   | RPM        | ok

Lo que significa: La CPU está caliente, pero los ventiladores no están a tope. Eso suele ser un problema de política de control (modo silencioso, mapeo de sensores equivocado) o un bloqueo físico.

Decisión: Escala a ajustes de perfil BIOS/BMC. Si no controlas eso, involucra a quien maneje el firmware de plataforma. El software por sí solo no hará girar los ventiladores más rápido si el BMC no lo permite.

Tarea 16: Comprobación rápida de “ayudantes” en segundo plano (tlp/power-profiles-daemon)

cr0x@server:~$ systemctl status power-profiles-daemon.service --no-pager
● power-profiles-daemon.service - Power Profiles daemon
     Loaded: loaded (/lib/systemd/system/power-profiles-daemon.service; enabled)
     Active: active (running) since Mon 2025-12-29 10:52:11 UTC; 25min ago

Lo que significa: Un daemon puede estar imponiendo comportamiento “balanced”. En portátiles esto es normal. En nodos de almacenamiento puede ser un asesino silencioso de rendimiento.

Decisión: Decide explícitamente: ¿nodo de rendimiento o no? Si sí, fija el perfil de performance y documéntalo. Si no, acepta el techo de rendimiento.

Estrangulamiento específico de almacenamiento: NVMe, PCIe y “¿por qué fio miente?”

El rendimiento de almacenamiento es una cadena: la CPU envía I/O, el kernel lo encola, PCIe lo mueve, el controlador lo atiende, la NAND hace el trabajo y el controlador intenta no derretirse. Puedes estrangular en cualquier eslabón.

El estrangulamiento NVMe suele ser problema del controlador, no de la NAND

El controlador NVMe es el punto caliente. La NAND tolera calor hasta cierto punto, pero el silicio y el encapsulado del controlador no. Muchas unidades reportan “Composite” temperature, pero también múltiples sensores. Si Sensor 1 sube mientras Composite se retrasa, estás viendo al controlador quemarse.

Las transiciones de gestión térmica (T1/T2) son la evidencia clara porque se contabilizan. Si puedes mostrar que thermal_management_t1_trans_count incrementa en la misma marca temporal en que tu rendimiento cae, has probado el caso con la propia documentación de la unidad.

Por qué los benchmarks cortos lo pasan por alto

Porque la unidad arranca relativamente fría, los modos turbo están activos, la caché SLC es generosa y el controlador no ha saturado su masa térmica. Luego se calienta. Luego el firmware restringe. El primer minuto es una mentira que te cuentas a ti mismo.

La velocidad de enlace PCIe y ASPM pueden ser distracciones — o la historia completa

Si tu enlace PCIe está negociado a una velocidad menor, puedes limitar el rendimiento sin importar la capacidad de la unidad. A veces es configuración. A veces es recuperación de errores. A veces es calidad del riser/cable. A veces es “alguien instaló una unidad x4 en una ranura que comparte líneas con tres dispositivos más, y ahora aprendemos sobre topología”.

ASPM (ahorro de energía) puede causar picos de latencia, pero rara vez provoca por sí solo una caída sostenida y clara en el rendimiento. Los límites térmicos y de potencia sí lo hacen.

El acoplamiento feo entre CPU y almacenamiento

Puedes pensar que el almacenamiento es “limitado por I/O” y que la frecuencia de la CPU no importa. Luego activas sumas de verificación, compresión, cifrado, codificación por borrado o cargas de trabajo de IOPS altos y bloques pequeños. De repente la CPU hace trabajo real por I/O y la frecuencia importa. El throttling se convierte en menos IOPS, mayor latencia en cola y a veces narrativas extrañas de “el dispositivo está lento”.

Broma #2: Si quieres simular estrangulamiento térmico en una reunión, presenta tu gráfico y luego baja la voz poco a poco hasta que todos se aburran.

Arreglos que realmente ayudan: refrigeración, flujo de aire y contacto

Los arreglos de refrigeración no son glamorosos. También funcionan. Si quieres rendimiento sostenido, necesitas margen térmico sostenido. No “pasa una prueba de 30 segundos”. Sostenido.

1) Deja de recircular aire caliente

La mayoría de los “estrangulamientos misteriosos” en racks son flujo de aire. El servidor está inhalando su propio escape porque:

Faltan paneles ciegos.
La contención de pasillo caliente es aspiracional.
Los cables bloquean la entrada o crean turbulencia.
El servidor está metido en un sitio con mala entrega de aire frío.

Mide admisión vs escape vía IPMI. Si la admisión ya es alta antes de la carga, estás operando con margen reducido.

2) Asegúrate de que los ventiladores aumenten cuando deben

En muchos servidores, Linux no puede comandar directamente los ventiladores; lo hace el BMC. Si el BMC está en un perfil silencioso, dejará que la CPU llegue al límite y se estrangule, porque está optimizando acústica y longevidad de componentes. Tu trabajo es optimizar para rendimiento y previsibilidad.

La solución suele estar en BIOS/BMC: perfil térmico “Performance”, mínimos de ventilador más altos o mapeo correcto de sensores. Si no puedes cambiarlo, al menos documéntalo porque vives dentro de suposiciones ajenas.

3) Los disipadores y el flujo de aire para NVMe importan más de lo que crees

M.2 NVMe en servidores es una trampa clásica. Nació en portátiles donde el flujo de aire es mínimo pero el diseño del chasis es integrado. En servidores, la gente monta M.2 en una placa “porque cabe” y luego se pregunta por qué se estrangula. Las bahías U.2/U.3 suelen tener mejor flujo, pero aun así, bahías delanteras densas pueden calentarse.

Arreglos accionables:

Añadir disipadores adecuados (calificados por el proveedor si quieres tranquilidad de garantía).
Añadir guías de flujo o shrouds si el chasis los soporta.
Asegurar que dispositivos adyacentes de alta temperatura (GPUs, DPUs, HBAs) no estén vertiendo calor en la misma zona.

4) Volver a asentar y repastar (sí, de verdad)

Con los años, la pasta térmica puede degradarse. La presión de montaje puede desplazarse. El polvo aísla. He visto “regresiones de software” desaparecer después de limpiar un disipador que parecía un filtro de fieltro.

Cuándo hacerlo:

Un nodo del pool se estrangula antes que sus pares.
Los ventiladores se comportan normalmente, pero la temperatura CPU sube más rápido de lo esperado.
Problemas plausibles de contacto del disipador (mantenimiento reciente, transporte, vibración).

Sé disciplinado: programa downtime, sigue prácticas ESD, usa pasta conocida y verifica después con la misma instrumentación.

Arreglos para límites de potencia: RAPL, amd_pstate y restricciones por firmware

El estrangulamiento térmico y la limitación de potencia son primos que se prestan ropa. Puedes estar limitado por potencia mucho antes de estar al máximo térmico, especialmente en servidores configurados para “eficiencia” o presupuestos de potencia restringidos.

Gobernadores de CPU y perfiles de plataforma: deja de permitir que los valores por defecto gobiernen tu nodo de almacenamiento

Los valores por defecto están diseñados para sistemas de propósito general. Los nodos de almacenamiento que ejecutan I/O sostenido no son de propósito general. Si quieres rendimiento predecible, establece política explícita:

Gobernador CPU: performance (o al menos un ajuste afinado que evite bajadas dramáticas bajo carga).
Perfil de plataforma: performance (si es soportado).
Desactiva demonios orientados a portátiles en servidores a menos que tengas razón.

Configuración persistente del gobernador (systemd)

Para Debian, un enfoque limpio es una pequeña unidad systemd que fija el gobernador en el arranque. Es contundente, pero honesto. También puedes usar cpufrequtils, pero systemd hace explícita la intención y la versiona.

cr0x@server:~$ sudo tee /etc/systemd/system/cpupower-performance.service <<'EOF'
[Unit]
Description=Set CPU governor to performance
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set -g performance

[Install]
WantedBy=multi-user.target
EOF

cr0x@server:~$ sudo systemctl daemon-reload

cr0x@server:~$ sudo systemctl enable --now cpupower-performance.service
Created symlink /etc/systemd/system/multi-user.target.wants/cpupower-performance.service → /etc/systemd/system/cpupower-performance.service.

Decisión: Haz esto solo en nodos donde el rendimiento sostenido importe y entiendas potencia/termodinámica. De lo contrario “arreglarás el rendimiento” gastando más vatios y luego redescubrirás límites de refrigeración.

Intel RAPL: no subas límites a ciegas

El ajuste de RAPL puede ser efectivo, pero también es la forma de convertir “throttling predecible” en “apagados impredecibles” si la refrigeración no puede con la carga. Si subes PL1/PL2 sin arreglar el flujo de aire, solo estás moviendo el punto de fallo.

Qué hacer en su lugar:

Primero ajusta refrigeración/perfil de ventiladores para manejar la carga sostenida.
Luego valida potencia sostenida y temperatura del paquete con la carga real.
Solo entonces considera ajustar límites, y haz cambios pequeños y reversibles.

Sistemas AMD: pstate + CPPC pueden ir bien, hasta que el firmware se pone conservador

amd_pstate suele comportarse bien, pero aún puedes estar limitado por límites de plataforma (PPT/TDC/EDC) y restricciones térmicas. La vía de solución suele ser ajuste BIOS (perfil de rendimiento, límites térmicos, curvas de ventilador), no solo flags de Linux.

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

Esta sección existe porque los humanos repiten errores con convicción.

1) El rendimiento cae después de 1–3 minutos y luego se estabiliza bajo

Causa raíz: Estrangulamiento térmico NVMe (T1/T2), a menudo por pobre flujo de aire/contacto del disipador.

Solución: Añadir disipadores/guías de flujo, asegurar que los ventiladores escalen, mover unidades lejos de fuentes de calor, validar con contadores de nvme smart-log.

2) Las IOPS bajan mientras CPU Busy% permanece alto, temperatura CPU cerca del umbral

Causa raíz: Estrangulamiento térmico de CPU o limitación de potencia (PL1 limita frecuencia sostenida).

Solución: Arregla refrigeración primero (ventiladores/perfil/disipador), luego verifica gobernador y perfil BIOS de potencia. Usa turbostat + logs del kernel como evidencia.

3) El rendimiento va bien en arranque en frío, mal después de una actualización de firmware

Causa raíz: BIOS reseteado a perfil “Balanced” o “Acoustic”; límites de potencia cambiados; curva de ventilador alterada.

Solución: Vuelve a aplicar la configuración BIOS/BMC conocida. Trata las actualizaciones de firmware como cambios de configuración con checklist.

4) Un nodo en la flota es más lento con la misma configuración

Causa raíz: Variación física: polvo, ventilador fallando, pasta degradada, disipador mal asentado, baffle faltante.

Solución: Compara baselines IPMI entre nodos, inspecciona hardware, limpia y repasta si es necesario.

5) Picos de latencia, dmesg muestra errores AER corregidos

Causa raíz: Enlace PCIe marginal (riser/cable/slot) agravado por temperatura; el enlace puede reentrenarse a menor velocidad.

Solución: Reasentar/reemplazar riser, mover ranura, actualizar firmware, mejorar flujo de aire alrededor de la zona PCIe, confirmar velocidad de enlace negociada.

6) Después de “optimizar potencia”, el almacenamiento quedó más lento

Causa raíz: Gobernador/perfil de potencia demasiado conservador; estados C profundos o downclocking agregan latencia y limitan IOPS.

Solución: Fija política de performance en nodos de almacenamiento; mide vatios y temperaturas; no optimices potencia sin SLOs.

7) fio muestra números enormes, la app sigue lenta

Causa raíz: Benchmark no representativo: demasiado corto, profundidad de cola incorrecta, efectos de caché, no sostenido o no mide latencia tail.

Solución: Ejecuta pruebas sostenidas (10+ minutos), registra temperaturas y eventos de throttling, y mide p95/p99 de latencia en tu app.

Tres microhistorias del mundo corporativo

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

Una compañía operaba nodos de almacenamiento para ingestión de logs. Nada exótico: NVMe, Linux, una tubería simple. Llegó un lote nuevo de servidores, mismo proveedor, mismo nombre de modelo, “igual que antes”. El equipo los imbricó, los unió al clúster y se fueron a casa sintiéndose competentes.

Dos días después, la ingestión empezó a retrasarse cada tarde. No fue un fallo agudo, solo una deriva lenta hacia “por qué estamos otra vez atrasados”. Los gráficos eran insultantes: todo parecía bien por la mañana. Al mediodía, el rendimiento se hundía, la latencia subía y el backlog crecía. La gente culpó a la tubería, luego a la aplicación, luego a la red.

La suposición equivocada fue simple: “mismo nombre de modelo significa mismo comportamiento térmico”. Los nuevos servidores venían con un carrier NVMe distinto y un arreglo de baffles de flujo de aire diferente. En las unidades antiguas, el flujo frontal a trasbar lavaba el área NVMe. En las nuevas, el controlador NVMe quedó en un bolsillo de aire cálido detrás de una barrera plástica que parecía inofensiva hasta que la mediste.

Lo demostraron con dos líneas temporales: lecturas sostenidas con fio y los contadores de gestión térmica NVMe. Cada vez que el backlog crecía, thermal_management_t1_trans_count marcaba un incremento en sincronía. La solución no fue ingeniosa. Fue física: instalar el kit de baffle correcto, asegurar que los ventiladores estuvieran en perfil “performance” del proveedor y añadir disipadores a las unidades más calientes.

Tras el cambio, la caída de la tarde desapareció. El postmortem fue directo: habían tratado la variación de plataforma como irrelevante. La acción fue mejor: incluir parámetros térmicos en la aceptación de hardware, no esperar al llanto en producción.

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

Otra organización se tomó en serio la eficiencia energética. Buena intención, costos reales. Desplegaron una configuración “verde” en la flota: gobernador balanced, plataforma en modo ahorro y ajustes agresivos para comportamiento en reposo. En el tablero de potencia se veía bien.

Entonces sus jobs nocturnos empezaron a tardar más. No trágicamente más, solo lo suficiente para chocar con el pico matutino. Esa superposición causó latencia visible al usuario. El incidente fue lento, político y molesto: todos tenían un gráfico que apoyaba su narrativa favorita.

La optimización falló porque optimizaron la fase equivocada del día. El sistema pasaba muchas horas en carga moderada y picos cortos, donde el ahorro era real. Pero durante I/O sostenido con compresión, la CPU quedaba pegada. La política “balanced” bajaba la frecuencia más agresivamente de lo esperado y los límites de potencia sostenida impedían que la CPU mantuviera frecuencias más altas. No era solo “CPU más lenta”. Era “CPU más lenta justo cuando necesitábamos rendimiento sostenido”.

Lo demostraron capturando turbostat durante el batch: caída de frecuencia con Busy% alto, más logs del kernel indicando throttling. Las curvas de rendimiento de almacenamiento coincidían con la curva de frecuencia de forma casi embarazosa. Las NVMe no eran el limitador; el cómputo por I/O sí lo era.

La solución fue dividir políticas: mantener ahorro en nodos generales, pero fijar nodos de almacenamiento/batch en perfil performance durante ventanas de batch. Requirió proceso, no heroísmo: control de cambios, documentación y un servicio de arranque para fijar el gobernador. La potencia subió un poco. Los incidentes bajaron mucho.

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

Un equipo de servicios financieros operaba un clúster modesto con ZFS. No eran llamativos, pero sí disciplinados. Cada trimestre hacían una “prueba de resistencia de rendimiento sostenido” tras parches: 30 minutos de carga read/write, con temperatura y contadores de throttling recogidos y archivados.

Un trimestre, la prueba mostró algo raro: el rendimiento iba bien los primeros minutos, luego se hundía en torno a un tercio. La aplicación estaba bien, el kernel actualizado y nadie se había quejado todavía. En otras palabras: el momento perfecto para encontrar un problema, porque el negocio no estaba gritando.

Compararon la telemetría con el trimestre anterior y vieron dos diferencias: la temperatura del paquete CPU subía más rápido y las RPM del ventilador BMC se nivelaban más bajas. Una actualización de firmware había reseteado silenciosamente el perfil de ventilador. Nada “rompió”, así que no fue obvio. Pero la prueba de resistencia lo dejó claro.

Cambiaron el perfil BMC de vuelta a performance, volvieron a ejecutar la prueba y la caída desapareció. Sin incidente. Sin pánico. Solo una casilla y una re-ejecución.

El manager del equipo lo llamó “excelencia aburrida”, que es lo más amable que puedes decir de operaciones. La prueba no les hizo mejores para heroísmos; hizo heroísmos innecesarios.

Listas de verificación / plan paso a paso

Paso a paso: demostrar estrangulamiento de extremo a extremo (método repetible)

Elige una carga sostenida: 10–20 minutos, parámetros constantes. Evita pruebas de “burst”.
Inicia la carga con salida de estado: fio con --status-interval.
En paralelo, recoge telemetría CPU: turbostat cada 2 segundos.
En paralelo, recoge temperaturas: salida de sensors en watch.
En paralelo, captura contadores térmicos NVMe: snapshot de smart-log al inicio/medio/fin.
Marca las marcas de tiempo: anota la hora o registra todo en archivos.
Busca correlación: caída de rendimiento alineada con subida de temperatura y evidencia de límites térmicos/potencia.
Clasifica el cuello de botella: CPU vs NVMe vs enlace PCIe vs control de refrigeración.
Aplica una solución a la vez: perfil de ventilador O disipador O gobernador, no todo a la vez.
Repite la misma prueba: compara curvas, no un único número.

Lista de verificación de refrigeración (servidores)

¿Temperatura de admisión razonable bajo carga? Si no, arregla flujo de aire/contenimiento de rack.
¿Los ventiladores suben con temperatura CPU/NVMe? Si no, fija perfil BMC.
¿Paneles ciegos presentes? ¿Cables obstruyen admisión? Arréglalo.
¿NVMe tiene disipadores o flujo de aire? Si no, añádelo.
¿Un nodo está más caliente que sus pares? Inspecciona: polvo, salud del ventilador, pasta, baffles.

Lista de verificación de política de potencia (nodos Debian 13)

Confirma que el gobernador y el driver cpufreq coinciden con tu intención.
Busca demonios de gestión de potencia en servidores; quítalos o configúralos.
Valida perfil de plataforma/preset BIOS tras actualizaciones.
No subas límites de potencia a menos que la refrigeración esté probada para cargas sostenidas.

FAQ

1) ¿Cómo sé que es estrangulamiento térmico y no “comportamiento normal de caché SSD”?

Busca evidencia explícita: contadores de transición de gestión térmica NVMe (T1/T2) incrementándose, o mensajes de CPU “clock throttled”, alineados con la caída de rendimiento. Los efectos de caché no suelen incrementar contadores térmicos.

2) ¿Por qué mi benchmark se ve genial cuando lo repito justo después?

Porque detener la carga enfría el hardware. Reseteas el estado térmico. Las pruebas sostenidas revelan el techo en estado estacionario; las repeticiones cortas revelan el techo de ráfaga.

3) ¿Puede el throttling de CPU realmente reducir tanto el rendimiento de almacenamiento?

Sí, especialmente con compresión, checksums, cifrado, I/O de bloques pequeños, altas tasas de interrupción o stacks de usuario para almacenamiento. Si la CPU no puede enviar/manipular completaciones de I/O lo bastante rápido, las IOPS bajan.

4) ¿Debo siempre poner el gobernador CPU en performance en nodos de almacenamiento?

En nodos donde el rendimiento sostenido es parte del SLO, sí—después de validar refrigeración y presupuesto de potencia. En nodos de uso mixto o térmicamente limitados, puede que prefieras un enfoque balanced afinado.

5) ¿Son siempre necesarios los disipadores NVMe?

No siempre, pero suelen ser la forma más barata de prevenir throttling, especialmente para dispositivos M.2 o bahías densas U.2/U.3. Si tu NVMe llega a T1/T2 bajo carga sostenida, la respuesta es efectivamente “sí”.

6) Mis ventiladores están lentos pero las temperaturas altas. ¿Linux puede arreglar eso?

A veces en sobremesas; a menudo no en servidores. Muchos servidores usan el BMC para control de ventiladores. Necesitarás ajustes BIOS/BMC, no un parámetro mágico del kernel.

7) ¿Es seguro subir límites de potencia (PL1/PL2)?

Pue de serlo, si la plataforma está diseñada para ello y la refrigeración está verificada. Es inseguro si ya estás cerca de límites térmicos o si tu presupuesto de potencia por rack es ajustado. Arregla refrigeración primero y luego prueba.

8) ¿Qué hago si la velocidad de enlace PCIe muestra “downgraded” solo después de calentar?

Eso es señal de integridad de señal marginal o recuperación de errores bajo estrés. Revisa errores AER, reasienta/reemplaza risers, y mejora flujo de aire alrededor de dispositivos PCIe. No lo ignores; puede devenir en inestabilidad en la ruta de datos.

9) ¿Por qué se culpa a Debian 13 por esto?

Porque las actualizaciones del SO cambian valores por defecto (gobernadores, controladores, demonios) y a menudo coinciden con actualizaciones de firmware. El momento hace que la gente sospeche. A la física no le importa.

10) ¿Qué telemetría debo archivar para futuros debates “se volvió más lento”?

Salida de estado fio en el tiempo, resúmenes turbostat, snapshots de sensors, contadores nvme smart-log, volcados de sensores IPMI y logs del kernel con mensajes de throttle o AER.

Conclusión: siguientes pasos que puedes hacer hoy

Si tu rendimiento cae con el tiempo en Debian 13, asume estrangulamiento hasta demostrar lo contrario. No porque Debian sea frágil, sino porque el hardware moderno es agresivamente oportunista: acelera primero y negocia después.

Haz esto en orden:

Ejecuta una carga sostenida de 10–20 minutos y captura series temporales de rendimiento.
Captura temperatura/frecuencia de CPU y evidencia de throttling (turbostat + journal).
Captura contadores térmicos NVMe (nvme smart-log, smartctl).
Si puedes correlacionar la caída con evidencia térmica/potencia, arregla refrigeración/perfil de ventiladores primero.
Sólo entonces ajusta política de potencia (gobernadores, perfil de plataforma y—con cuidado—límites de potencia).
Vuelve a ejecutar la misma prueba sostenida y compara la curva completa, no un solo número destacado.

El objetivo es rendimiento sostenido y aburrido. La velocidad de ráfaga es para diapositivas de marketing. El rendimiento en estado estacionario es para producción.