La historia del regreso de Ryzen: por qué pareció repentino (pero no lo fue)

Un trimestre te dicen “compra Intel, es más seguro.” El siguiente trimestre tu director financiero pregunta por qué la flota del competidor cuesta menos, funciona más fría y, de alguna manera, termina las tareas más rápido. Mientras tanto, tu rotación de on-call aprende un nuevo tipo de dolor: no un fallo dramático, sino la silenciosa y crónica regresión de rendimiento que solo sucede en algunos hosts.

El ascenso de Ryzen pareció un giro argumental porque la industria ve lanzamientos de producto, no los años de ingeniería, coreografía de fabricación y disciplina operativa detrás de ellos. Si gestionas sistemas de producción, la historia de Ryzen es menos “el desvalido gana” y más “una apuesta arquitectónica dio resultado, y luego los equipos de ops se apresuraron a reaprender sus instintos.”

Por qué Ryzen pareció repentino

El mundo no despertó una mañana con una AMD mágicamente competente. Lo que ocurrió es más aburrido—y por eso más poderoso. AMD ejecutó un plan de varios años abarcando arquitectura, asociaciones en tecnología de procesos, estabilidad de plataforma y segmentación de producto. El retorno llegó de una forma que pareció abrupta porque el mercado llevaba tiempo estancado en una meseta.

Si comprabas CPUs en la era previa a Ryzen, básicamente optimizabas por previsibilidad: comportamiento de plataforma consistente, flags de compilador predecibles, valores por defecto del BIOS ajustados por el proveedor y “las rarezas que ya conocemos.” Luego llegó Zen y ofreció una propuesta de valor distinta: muchos núcleos, IPC competitivo y rendimiento por dólar que hizo sonreír a los equipos de compras como si hubieran encontrado un error de facturación.

Ese es el sentimiento de “repentino”: un espacio de decisiones previamente conservador se volteó. No porque la física cambiara, sino porque los trade-offs se movieron. Y porque el ritmo de Intel en ese momento dejó a AMD un blanco amplio. Cuando un actor se ralentiza, el otro no necesita ser perfecto. Solo tiene que enviar piezas competentes sin descanso.

Aquí está la verdad operativa: el regreso de Ryzen fue también el regreso de la complejidad opcional. Obtienes más perillas—disposiciones NUMA, comportamiento de topología de memoria, características de interconexión—además de la habitual sopa de parámetros de BIOS y kernel. La ventaja de rendimiento era real, pero también la posibilidad de hacerse daño.

Conclusión que cambia decisiones: Ryzen no fue “una CPU nueva.” Fue un nuevo conjunto de restricciones. Trátalo como adoptar un backend de almacenamiento nuevo: realiza benchmarks, caracteriza, estandariza y luego escala.

Qué cambió realmente bajo el capó (y por qué importó)

Zen fue un reinicio, no una iteración

Zen no fue “vamos a ajustar Bulldozer.” Fue AMD reconstruyendo su enfoque central: mayor IPC, mejor predicción de saltos, jerarquía de caché mejorada y un núcleo moderno que pudiera ganar en trabajo por hilo y escalar entre muchos hilos. El objetivo no era solo vencer un benchmark; era construir una plataforma que pudiera anclar Ryzen de consumo y EPYC de servidor sin convertirse en una feria de ciencias de ingeniería.

Desde la perspectiva SRE, Zen posibilitó algo más: escalado de rendimiento predecible. No perfecto—nada lo es—pero lo bastante bueno como para que la planificación de capacidad volviera a usar “núcleos × frecuencia × perfil de carga” sin reír nerviosamente.

Los chiplets cambiaron la economía y luego la flota

El enfoque de chiplets de AMD es una decisión que parece obvia después de verla funcionar. Separar dies de computación del(los) die(s) de E/S. Fabricar el compute denso y caliente en un nodo de vanguardia. Poner controladores de E/S y memoria en un nodo más maduro. Mejora de rendimiento por fabricación, diversificación de bines y la compañía puede enviar más SKUs sin apostar la granja a un solo die monolítico.

En la práctica esto hizo dos cosas:

• Mejoró el suministro y el precio/rendimiento: mejores rendimientos y binning flexible se traducen en “más núcleos a un precio dado.”
• Creó realidades de topología: la distancia entre un núcleo y su controlador de memoria, o entre núcleos en distintos chiplets, importa. La latencia deja de ser un error de redondeo.

Por eso Ryzen (y especialmente EPYC) puede ser tanto un sueño como una trampa. Si tu carga es intensiva en throughput, ganas a lo grande. Si eres sensible a la latencia y descuidado con la localidad de memoria, puedes perder frente a una CPU “más lenta” porque accidentalmente construiste una lotería de memoria remota.

Infinity Fabric: el interconexión que ignoras hasta que te pasa factura

Infinity Fabric de AMD es la autopista interna que conecta chiplets y el die de E/S. No es solo marketing; es una restricción práctica. La frecuencia del fabric y las configuraciones de memoria interactúan. Los valores por defecto del BIOS suelen ser “seguros,” lo que en términos de rendimiento significa “adecuado para el escritorio promedio, subóptimo para tu base de datos de producción.”

Qué hacer: Estandariza versiones de BIOS y perfiles de memoria en toda la flota y trata los ajustes relacionados con el fabric como parte de la plataforma, no como “trivias de ajuste”.

El ecosistema de la plataforma maduró (silenciosamente)

Cuando la gente dice “Ryzen mejoró,” a menudo se refieren a “controladores, BIOS, microcódigo, planificación del kernel y firmware dejaron de ser picantes.” La era temprana de Zen experimentó una maduración real de plataforma con el tiempo. Esa maduración es invisible para consumidores que actualizan cada pocos años, pero dolorosamente visible para SREs que gestionan 400 nodos idénticos y necesitan que se comporten de forma idéntica.

Una de las victorias menos glamurosas: los planificadores de Linux y el comportamiento de balanceo NUMA mejoraron para la topología de AMD. Eso no es un titular, pero es una razón por la que un despliegue Ryzen/EPYC en 2023 se siente más suave que uno en 2017.

Opinión: Si quieres que Ryzen parezca “repentino” e indoloro, debes hacer el trabajo no repentino: disciplina de firmware, disciplina de versión de kernel y benchmarks repetibles. Si no, culparás a la CPU por tu propia inconsistencia.

Hechos y contexto que aclaran la línea temporal

Esto no es trivia. Son puntos de “ah, por eso” que explican por qué el ascenso de Ryzen parece abrupto para los externos.

1. Zen (2017) fue el primer diseño de núcleo verdaderamente competitivo de AMD en años y reajustó las expectativas de IPC tras la era Bulldozer/Piledriver.
2. La primera generación de EPYC (Naples, 2017) puso los recuentos de núcleos sobre la mesa de una forma que obligó a compradores de servidores a reconsiderar “Intel por defecto.”
3. El diseño de chiplets escaló más rápido que los dies monolíticos porque los rendimientos y el binning facilitan enviar piezas de alto conteo de núcleos de manera consistente.
4. Infinity Fabric vinculó el comportamiento de memoria e interconexión, haciendo que la configuración de memoria sea más relevante para el rendimiento de CPU de lo que muchos equipos estaban acostumbrados.
5. Zen 2 (2019) movió el cómputo a un nodo más pequeño mientras usaba un die de E/S separado, mejorando la eficiencia y a menudo el rendimiento por vatio en flotas reales.
6. Zen 3 (2020) mejoró las relaciones núcleo-caché y redujo las penalizaciones de comunicación entre núcleos, lo que ayudó a cargas sensibles a la latencia y mixtas.
7. Las mitigaciones de seguridad llegaron de forma desigual entre proveedores y generaciones; las “regresiones” de rendimiento a veces tuvieron más que ver con mitigaciones que con el silicio.
8. Los proveedores cloud validaron AMD a escala, lo que cambió la percepción de riesgo empresarial: “Si ellos lo ejecutan, nosotros también podemos.”
9. Las herramientas y la planificación del kernel se pusieron al día: el ecosistema Linux aprendió nuevos patrones de topología y mejoró valores por defecto.

El ángulo SRE: el rendimiento es una característica de fiabilidad

En producción, el rendimiento no es un lujo. Es el margen que te salva de recibir paginaciones a las 3 a.m. Cuando la reserva de CPU se reduce, todo lo demás empeora: latencia de solicitudes, profundidad de colas, pausas de GC, retraso de replicación, backlogs de compactación, handshakes TLS, incluso “misteriosas” pérdidas de paquetes por softirqs sobrecargados.

El regreso de Ryzen importó porque cambió lo que significa “reserva razonable por dólar”. Eso modifica decisiones arquitectónicas. Cambia cuántas réplicas puedes permitirte. Cambia cuán agresivo puedes ser con cifrado, compresión y observabilidad.

Pero también cambió los modos de fallo. Alto conteo de núcleos y diseños multi-chiplet amplifican problemas que antes podías ignorar:

• NUMA importa otra vez: el acceso remoto a memoria se vuelve un impuesto medible.
• El comportamiento del planificador importa: la colocación de hilos puede ser la diferencia entre un p99 estable y jitter crónico.
• La velocidad y tiempos de memoria importan: “arranca” no es un plan de rendimiento.

Una cita que debería colgar en la pared de todos los equipos de ops, porque es ruda y precisa:

“Todo falla, todo el tiempo.” — Werner Vogels

Ryzen no cambió eso. Solo cambió dónde sentirás la falla primero: en las suposiciones que traías de la plataforma anterior.

Broma #1: La CPU no estuvo “más lenta tras la actualización.” Tu monitorización simplemente empezó a decir la verdad con mayor resolución.

Tres microhistorias corporativas desde las trincheras

Microhistoria 1: El incidente causado por una suposición errónea (NUMA como pensamiento secundario)

La Compañía A migró una capa API sensible a la latencia desde servidores antiguos de doble socket a relucientes hosts AMD de alto conteo de núcleos. La migración fue “simple”: crear una nueva imagen, ejecutar la misma versión de Kubernetes, redirigir tráfico gradualmente. Los dashboards parecían bien—hasta que no lo estaban. El p95 estaba cómodo, el p99 empezó a oscilar y una vez por hora la tasa de errores hacía un pico como un latido.

El ingeniero de on-call persiguió a los sospechosos habituales: retransmisiones de red, vecinos ruidosos, IO de disco, recolección de basura. Nada obvio. La utilización de CPU nunca superó el 55%, lo que hizo que el incidente fuera insultante. Los usuarios se quedaban en timeout mientras las CPUs “descansaban”.

La causa raíz fue una suposición errónea: que “una CPU grande es un gran pool.” La aplicación tenía un modelo hilo-por-núcleo y un caché en memoria grande. Kubernetes estaba dispersando pods e hilos entre nodos NUMA, y las asignaciones de memoria aterrizaban donde el allocador se sentía afortunado. El resultado: picos de acceso a memoria remota. No constantes, pero correlacionados con la agitación del caché y tareas periódicas en segundo plano. Jitter clásico en p99.

La solución no fue heroica. Fue aburrida: fijar pods a nodos NUMA, usar políticas de afinidad de CPU y memoria y validar con un microbenchmark de latencia simple bajo carga. También estandarizaron configuraciones de BIOS y desactivaron un par de “funciones de ahorro de energía” que eran geniales para escritorios y mediocres para latencias de cola.

Conclusión que cambia decisiones: Si asumes “NUMA no importa,” Ryzen terminará enviándote una factura con intereses.

Microhistoria 2: La optimización que salió mal (sobreajuste de memoria y fabric)

La Compañía B ejecutaba un clúster analítico intensivo en almacenamiento. Leyeron que la velocidad de memoria y el ajuste de Infinity Fabric podían desbloquear rendimiento. Así que hicieron lo que los ingenieros siempre hacen cuando se emocionan: ajustaron agresivamente y lo desplegaron rápido.

Aumentaron clocks de memoria, ajustaron timings, habilitaron un perfil BIOS “optimizados” y celebraron ganancias tempranas en benchmarks. Luego la producción empezó a ver errores de máquina y reinicios esporádicos. No suficientes para reproducir bajo demanda. Justo lo bastante para envenenar la confianza en toda la flota.

El fallo fue simple: el ajuste fue estable bajo benchmarks sintéticos de CPU pero marginal bajo cargas mixtas sostenidas con alta presión de memoria y variación de temperatura. Un subconjunto de DIMMs funcionaba bien con las configuraciones ajustadas en un laboratorio frío y era inestable en un rack cálido durante horas pico. Las configuraciones de fabric y memoria interaccionaron con los márgenes de error, y ECC corrigió la mayoría de errores—hasta que no pudo.

Revirtieron a un perfil de memoria conservador, re-cualificaron DIMMs e introdujeron una regla: no hay tuning de BIOS sin un burn-in que incluya presión de memoria, IO y soak térmico. Los benchmarks no son producción. La producción es rencorosa.

Conclusión que cambia decisiones: “Estable en un benchmark” no es “estable en una flota.” Trata el tuning de BIOS como un deploy de código: despliegue por fases, canary, plan de rollback.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día (disciplina de firmware)

La Compañía C tenía una flota mixta: algo de Intel, algo de AMD, varios fabricantes de placas base, múltiples versiones de BIOS. Al principio decidieron que eso era inaceptable. Crearon una línea base de plataforma: una lista corta de versiones de BIOS aprobadas, paquetes de microcódigo, versiones de kernel y un pequeño conjunto de ajustes de potencia/rendimiento. También mantuvieron una lista de materiales “conocida como buena” para DIMMs y NICs.

La gente se quejó. Las líneas base se sienten lentas. “¿Por qué no puedo actualizar el BIOS de mi clúster?” Porque “mi clúster” se convierte en “nuestro incidente” cuando un bug de caso límite golpea. Hicieron cumplir la línea base con comprobaciones de provisión y auditorías periódicas.

Entonces llegó una actualización de microcódigo que cambió características de rendimiento para un subconjunto de cargas criptográficas. Otros equipos en su industria vieron regresiones de latencia y pasaron semanas bisecando versiones de kernel. La Compañía C vio el cambio rápidamente porque tenían canarios fijados a la línea base y una suite de benchmarks repetible vinculada a cada actualización de firmware.

Pausaron el despliegue, ajustaron la planificación de capacidad y solo entonces ampliaron la implementación. Sin outage. Sin drama. Solo un postmortem ligeramente satisfecho que decía: “Notamos el problema antes de que notara a nuestros clientes.”

Conclusión que cambia decisiones: La disciplina de firmware es aburrida del mismo modo que lo son los cinturones de seguridad.

Tareas prácticas: comandos, salidas, decisiones

No “sientes” el rendimiento de Ryzen. Lo mides. A continuación hay tareas prácticas que puedes ejecutar en hosts Linux (bare metal o VM, según aplique). Cada una incluye qué significa la salida y qué decisión tomar.

Tarea 1: Identificar modelo de CPU, sockets y topología básica

cr0x@server:~$ lscpu
Architecture:             x86_64
CPU(s):                   64
Thread(s) per core:       2
Core(s) per socket:       32
Socket(s):                1
NUMA node(s):             2
Model name:               AMD EPYC 7543 32-Core Processor
L3 cache:                 256 MiB
NUMA node0 CPU(s):        0-31
NUMA node1 CPU(s):        32-63

Significado: Tienes 2 nodos NUMA incluso en un único socket. Eso es normal para muchos diseños EPYC. Tu carga podría estar cruzando nodos sin darse cuenta.

Decisión: Si te importa la latencia de cola, planifica afinidad NUMA y políticas de memoria. Si eres bound por throughput, puedes aceptar los valores por defecto.

Tarea 2: Comprobar versiones de kernel y microcódigo (hacer cumplir la línea base)

cr0x@server:~$ uname -r
6.1.0-18-amd64
cr0x@server:~$ dmesg | grep -i microcode | tail -n 3
[    0.412345] microcode: CPU0: patch_level=0x0a20120a
[    0.412346] microcode: CPU1: patch_level=0x0a20120a
[    0.412347] microcode: Microcode Update Driver: v2.2.

Significado: La versión del kernel afecta al planificador y al comportamiento NUMA; el microcódigo puede afectar a la estabilidad y al rendimiento.

Decisión: Si los hosts difieren, deja de comparar benchmarks entre ellos. Normaliza a una línea base antes de hacer “ciencia.”

Tarea 3: Inspeccionar distancias NUMA (visibilidad del peaje por acceso remoto)

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 0 size: 257751 MB
node 0 free: 241120 MB
node 1 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
node 1 size: 257751 MB
node 1 free: 239998 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

Significado: Distancia 21 vs 10 implica un salto de latencia material cuando hilos en el nodo 0 acceden memoria asignada en el nodo 1.

Decisión: Si tu carga es sensible, aplica localidad (pinning de procesos, cpuset de cgroups, política de memoria NUMA).

Tarea 4: Verificar el gobernador de frecuencia actual de la CPU (evitar modo ahorro accidental)

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

Significado: El gobernador afecta qué tan rápido suben las frecuencias bajo carga. Algunos gobernadores pueden añadir jitter de latencia.

Decisión: Para servicios críticos de latencia, considera ajustes de rendimiento consistentes (a menudo el gobernador “performance”) tras validar térmicas y presupuesto de potencia.

Tarea 5: Comprobar throttling y eventos térmicos (asesinos silenciosos de rendimiento)

cr0x@server:~$ journalctl -k | grep -iE 'throttle|thermal|hwmon' | tail -n 5
Jan 10 09:12:41 server kernel: CPU0: Core temperature above threshold, cpu clock throttled
Jan 10 09:12:41 server kernel: CPU0: Package temperature/speed normal

Significado: El throttling puede hacer que una “CPU rápida” se comporte como una mediocre, especialmente bajo carga sostenida.

Decisión: Arregla refrigeración, flujo de aire y límites de potencia antes de ajustar software. Si no puedes mantenerla fría, no puedes mantenerla rápida.

Tarea 6: Validar velocidad de memoria y población de canales (chequeo de realidad fabric/memoria)

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Locator|Speed|Configured Memory Speed' | head -n 12
Locator: DIMM_A1
Speed: 3200 MT/s
Configured Memory Speed: 3200 MT/s
Locator: DIMM_B1
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Locator: DIMM_C1
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s

Significado: Los DIMMs pueden ser capaces de 3200 MT/s, pero la plataforma los está ejecutando a 2933 MT/s (a menudo por reglas de población o valores por defecto del BIOS).

Decisión: Si el rendimiento está limitado por memoria, arregla la población de DIMMs y la configuración del BIOS; no te limites a “añadir más nodos.”

Tarea 7: Confirmar ECC habilitado y revisar conteos de errores corregidos

cr0x@server:~$ sudo edac-util -v
edac-util: EDAC drivers are loaded.
mc0: 0 CE, 0 UE
mc1: 12 CE, 0 UE

Significado: Errores corregidos (CE) no son gratuitos; indican margen degradado. No corregidos (UE) son alarma roja.

Decisión: Si CE está subiendo, programa reemplazo de DIMM y considera reducir el tuning de memoria. No esperes a que UE “te enseñe”.

Tarea 8: Identificar si estás limitado por CPU o bloqueado en IO

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
 2  0      0 241120  18244 981232    0    0     3    12  540 1020 12  3 84  1  0
 8  0      0 241100  18244 981240    0    0     0     0 1240 5900 58  8 33  1  0
 9  0      0 241090  18244 981260    0    0     0     4 1320 6100 61  9 28  2  0

Significado: Alto r con poco idle (id) sugiere contención de CPU. Alto wa sugiere espera de IO. Altos cambios de contexto (cs) pueden indicar presión del planificador.

Decisión: Si estás CPU-bound, investiga colocación de hilos, hotspots y comportamiento de frecuencia. Si estás IO-bound, deja de culpar a la CPU y perfila almacenamiento/red.

Tarea 9: Encontrar utilización por núcleo y presión de softirq (servicios intensivos en red)

cr0x@server:~$ mpstat -P ALL 1 3 | tail -n 8
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Average:      0    72.00    0.00   12.00    0.00    0.00    6.00    0.00    0.00    0.00   10.00
Average:      1     8.00    0.00    3.00    0.00    0.00   65.00    0.00    0.00    0.00   24.00
Average:     31     5.00    0.00    2.00    0.00    0.00    1.00    0.00    0.00    0.00   92.00

Significado: CPU1 está dominada por softirq, a menudo por procesamiento de red. Un núcleo caliente puede capar el throughput mientras la “CPU total” parece estar bien.

Decisión: Investiga afinidad de IRQ, ajustes RPS/XPS, conteo de colas NIC y si accidentalmente fijaste todas las interrupciones a un solo nodo NUMA.

Tarea 10: Medir latencia de cola del planificador y cambios de contexto con perf

cr0x@server:~$ sudo perf stat -e context-switches,cpu-migrations,cycles,instructions,cache-misses -a -- sleep 10
 Performance counter stats for 'system wide':

     18,240,112      context-switches
        420,331      cpu-migrations
  42,901,112,004      cycles
  61,221,990,113      instructions              #    1.43  insn per cycle
   1,220,991,220      cache-misses

      10.001234567 seconds time elapsed

Significado: Altas migraciones pueden implicar que el planificador está moviendo hilos entre núcleos/nodos NUMA, dañando la localidad de caché. IPC da una señal de salud; fallos de caché apuntan a presión de memoria.

Decisión: Si las migraciones son altas y la latencia inestable, aplica afinidad o investiga límites de CPU de contenedores/políticas de pinning.

Tarea 11: Comprobar residencia en C-states (jitter de latencia y costos de wake-up)

cr0x@server:~$ sudo powertop --time=1 --html=/tmp/powertop.html >/dev/null 2>&1
cr0x@server:~$ ls -lh /tmp/powertop.html
-rw-r--r-- 1 root root 188K Jan 10 09:44 /tmp/powertop.html

Significado: El informe muestra cuánto tiempo pasan las CPUs en C-states profundos. El sueño profundo ahorra energía pero puede añadir latencia de wake.

Decisión: Para servicios con latencia de cola, considera limitar C-states profundos en BIOS o parámetros de kernel—tras medir impacto en consumo y térmicas.

Tarea 12: Validar transparent huge pages y riesgo de fragmentación de memoria

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Significado: THP “always” puede ayudar a algunas cargas y perjudicar a otras (picos de latencia en defrag/compaction). Ryzen no es especial aquí, pero conteos mayores de núcleos pueden amplificar la contención del allocador.

Decisión: Para bases de datos y servicios críticos de latencia, prueba madvise o never en lugar de heredar valores por defecto.

Tarea 13: Confirmar que el balanceo NUMA automático hace lo que crees

cr0x@server:~$ cat /proc/sys/kernel/numa_balancing
1

Significado: El balanceo NUMA automático puede mejorar la localidad para algunas cargas, o introducir escaneos y jitter para otras.

Decisión: Si ves picos periódicos de latencia y migraciones altas, prueba desactivarlo en un canary y compara p99/p999.

Tarea 14: Comprobar señales de ancho de banda y latencia de memoria (rápido y sucio)

cr0x@server:~$ grep -E 'MemTotal|MemFree|MemAvailable' /proc/meminfo
MemTotal:       528898032 kB
MemFree:        241120000 kB
MemAvailable:   410552000 kB

Significado: No es una prueba de ancho de banda, pero es una comprobación de cordura. Si MemAvailable es baja, el sistema está bajo presión de memoria y puede estar reclamando/compactando, lo que puede imitar “CPU lenta”.

Decisión: Si la presión de memoria es alta, arregla eso primero (tamaño de caché, colocación de carga) antes de culpar a la generación de CPU.

Tarea 15: Verificar que disco y sistema de archivos no son el verdadero cuello de botella (reflejo del ingeniero de almacenamiento)

cr0x@server:~$ iostat -xz 1 3
Device            r/s     w/s   rKB/s   wKB/s  avgrq-sz  avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         12.00   90.00   384.0  9216.0     184.0      3.20   28.10    5.20   31.10   0.45  46.80

Significado: await y avgqu-sz sugieren encolamiento. Si el almacenamiento está encolando, tu CPU está esperando IO, no “yendo lenta”.

Decisión: Si %util es alto y await sube bajo carga, trabaja en almacenamiento: profundidades de cola, planificador IO, opciones de sistema de archivos o salud NVMe.

Tarea 16: Comprobar características de virtualización y si estás dentro de una VM (no hagas benchmarks equivocados)

cr0x@server:~$ systemd-detect-virt
none
cr0x@server:~$ lscpu | grep -i hypervisor

Significado: Si estás en una VM, la topología de CPU y el comportamiento de frecuencia pueden estar virtualizados y ser engañosos.

Decisión: Haz benchmarks en bare metal o asegúrate de que el hipervisor exponga topología y pinning consistentes; de lo contrario los resultados son ficción de rendimiento.

Broma #2: Hacer benchmarks en una VM ruidosa y llamarlo “ciencia CPU” es como cronometrar un maratón en una cinta mientras alguien cambia la inclinación.

Guía rápida de diagnóstico (primero/segundo/tercero)

Esta es la guía de “está lento, los clientes están molestos y tienes 15 minutos”. El objetivo no es elegancia. El objetivo es encontrar el cuello de botella dominante rápido y elegir la siguiente acción.

Primero: clasifica el cuello de botella (CPU vs memoria vs IO vs planificador)

• Revisa saturación y espera de CPU: vmstat 1 y mpstat. Si id es bajo y r es alto, estás CPU-bound. Si wa es alto, suele ser IO-bound. Si un núcleo está a tope en softirq, suele ser red/afinidad de IRQ.
• Revisa encolamiento de disco: iostat -xz 1. Alto await con avgqu-sz creciente significa que el almacenamiento está en el camino.
• Revisa presión de memoria: grep MemAvailable /proc/meminfo y dmesg en busca de advertencias OOM/reclaim. La presión de memoria a menudo se hace pasar por “la CPU se volvió lenta”.

Segundo: confirma topología y colocación (NUMA + pinning)

• Topología: lscpu y numactl --hardware. Si tienes múltiples nodos NUMA, asume que la memoria remota es posible.
• Migraciones: perf stat con cpu-migrations. Altas migraciones sugieren mala afinidad o restricciones de cgroup que causan rebote.
• Colocación de contenedores: Valida cpuset y política de memoria si ejecutas Kubernetes o slices systemd. No adivines—inspecciona.

Tercero: revisa los “asesinos silenciosos” (firmware, throttling, mitigaciones)

• Throttling: logs del kernel para eventos térmicos. Arregla refrigeración y límites de potencia antes de tunear.
• Deriva de firmware: versiones de kernel + microcódigo. Una flota con BIOS mezclados hace el rendimiento impredecible.
• Mitigaciones y parámetros del kernel: Si una actualización reciente cambió el rendimiento, compara parámetros de arranque y líneas base de microcódigo. No desactives mitigaciones a la ligera; cuantifica el impacto e involucra seguridad en la decisión.

Regla: No tunees lo que no hayas medido. No midas lo que no puedas reproducir. No reproduzcas en un sistema que no puedas describir.

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

Aquí es donde morderá a los equipos que encontraron a Ryzen “repentino”: usan el modelo mental antiguo en la nueva plataforma.

1) Síntoma: jitter en p99 después de migrar a Ryzen/EPYC

Causa raíz: accesos remotos a memoria NUMA debido a la colocación del planificador y al comportamiento del allocador entre nodos/chiplets.

Solución: Fija procesos/pods por nodo NUMA; usa cpusets; verifica con numastat y perf; ajusta o desactiva el balanceo NUMA automático si añade jitter.

2) Síntoma: uso de CPU “bajo”, pero el throughput está limitado

Causa raíz: un núcleo saturado en softirq/gestión de IRQ; mala afinidad de NIC; hotspot single-thread.

Solución: Inspecciona mpstat por dominancia de softirq; reparte IRQs entre cores/nodos NUMA; aumenta colas NIC; arregla el hotspot o paraleliza ese camino caliente.

3) Síntoma: benchmarks geniales, producción inestable (reinicios/MCE raros)

Causa raíz: ajustes de memoria/fabric sobreoptimizados con soak térmico insuficiente y validación de cargas mixtas.

Solución: Revertir a perfiles JEDEC estables; validar con pruebas de estrés largas; monitorizar errores EDAC corregidos; reemplazar DIMMs marginales.

4) Síntoma: “mismo SKU”, rendimiento diferente entre hosts

Causa raíz: deriva de firmware (BIOS/microcódigo), distinta población de DIMMs, distintos límites de potencia o diferencias térmicas.

Solución: Hacer cumplir una línea base de plataforma; auditar versiones BIOS; estandarizar DIMMs y curvas de ventiladores; verificar ajustes de potencia/rendimiento.

5) Síntoma: la frecuencia de CPU no sube, servicio se siente lento bajo ráfaga

Causa raíz: gobernador conservador, C-states profundos o política de potencia ajustada para eficiencia sobre latencia.

Solución: Evaluar cambios de gobernador; considerar limitar C-states profundos; medir impacto en latencia de cola antes/después.

6) Síntoma: “más núcleos” no redujo el tiempo de trabajo

Causa raíz: cuello de botella en ancho de banda de memoria, contención por locks o IO. Los núcleos no arreglan la serialización.

Solución: Perfilado: medir fallos de caché, cola de ejecución, espera IO; fragmentar trabajo; reducir contención por locks; mejorar localidad; escalar el verdadero cuello (canales de memoria, NVMe, red).

7) Síntoma: aumenta el retraso de replicación de la base de datos en hosts nuevos

Causa raíz: colocación NUMA mixta, comportamiento de THP o encolamiento de almacenamiento bajo patrones IO distintos.

Solución: Fija procesos DB; establece política THP apropiada para la BD; ajusta planificador IO y profundidades de cola; verifica con iostat y métricas a nivel DB.

Listas de verificación / plan paso a paso

Estos son los pasos operativos que convierten “Ryzen se ve genial en papel” en “Ryzen se comporta en prod.” Son deliberadamente poco románticos.

Checklist 1: Pre-compra y selección de plataforma (no compres sorpresas)

1. Elige 2–3 cargas representativas (API de latencia, análisis por lotes, trabajo intensivo en almacenamiento).
2. Define criterios de éxito en términos de producción: p99, throughput por vatio, coste por unidad de trabajo, impacto en el budget de errores.
3. Requiere un BOM de hardware que incluya modelo exacto de DIMM y plan de población; evita partes “equivalentes” a menos que estén probadas.
4. Decide si tu carga se preocupa por NUMA. Si sí, presupuestar tiempo de ingeniería para afinidad y colocación.
5. Confirma que NIC y almacenamiento alineen con la topología NUMA (por ejemplo, NIC en el mismo nodo que los cores más ocupados).

Checklist 2: Puesta en marcha y línea base (hacer hosts comparables)

1. Establece una versión de BIOS aprobada y aplícala a cada host antes de benchmarkear.
2. Bloquea una versión de kernel y un paquete de microcódigo; documéntalos como un contrato API.
3. Registra salidas de lscpu y numactl --hardware por clase de hardware.
4. Valida velocidad de memoria y salud ECC (dmidecode + edac).
5. Ejecuta un burn-in que incluya CPU, presión de memoria, IO y soak térmico; guarda logs.

Checklist 3: Estrategia de despliegue (evita el “misterio regresivo en toda la flota”)

1. Canary: desplegar a un pequeño porcentaje de tráfico y mantenerlo el tiempo suficiente para ver patrones diurnos.
2. Compara manzanas con manzanas: misma versión de software, mismo kernel, mismo BIOS, misma política de potencia.
3. Monitorea p99/p999 y tasa de errores, no la latencia media. Las medias son donde van a esconderse los incidentes.
4. Valida afinidad de IRQ y CPU si es intensivo en red; vigila núcleos calientes por softirq.
5. Automatiza detección de deriva para BIOS/microcódigo/kernel; trata la deriva como precursor de incidentes.

Checklist 4: Configuración consciente de NUMA (si te importa la latencia de cola)

1. Fija los procesos principales del servicio a un nodo NUMA (o conjunto de cores) y mantiene la memoria local.
2. Co-ubica las interrupciones más intensas y los hilos más calientes donde sea posible (mismo nodo).
3. Prueba con y sin balanceo NUMA automático en canaries; elige según estabilidad de p99.
4. Documenta la política para que futuros ingenieros no la “limpien” durante un refactor.

Preguntas frecuentes

1) ¿Ryzen “repentinamente” venció a Intel?

No. Fue una rampa de múltiples generaciones: Zen estableció competitividad, Zen 2 mejoró eficiencia y escalado, Zen 3 mejoró comportamiento para cargas sensibles a la latencia. La percepción del mercado tardó en alcanzar la ejecución.

2) ¿Por qué los chiplets importan en despliegues reales?

Cambian la dinámica de coste y suministro (mejores rendimientos) y cambian las características de rendimiento (topología y latencia). Obtienes más núcleos por dólar, pero debes respetar la localidad.

3) ¿Ryzen solo es bueno para cargas multihilo?

Destaca en trabajo intensivo en throughput, pero los núcleos Zen modernos también son fuertes por hilo. La pregunta mayor es si tu carga está limitada por latencia de memoria, ancho de banda o IO.

4) ¿Por qué mis benchmarks discrepan entre servidores que parecen idénticos?

“Aparentemente idénticos” a menudo no lo son: versiones BIOS, microcódigo, población de DIMMs, límites de potencia y térmicas difieren. Establece la línea base de la plataforma antes de creer resultados.

5) ¿Debería desactivar mitigaciones de seguridad para recuperar rendimiento?

No por defecto. Cuantifica el impacto, involucra a seguridad y considera mitigaciones dirigidas solo con un modelo de amenaza claro. De lo contrario te optimizarás hacia un incidente evitable.

6) ¿Cuál es la forma más rápida de saber si NUMA me está perjudicando?

Revisa lscpu / numactl --hardware para múltiples nodos, luego busca migraciones altas (perf stat) y jitter en p99 bajo carga. Si el pinning mejora la latencia de cola, NUMA formaba parte del impuesto.

7) ¿Ayudan los “perfiles de rendimiento” del BIOS?

A veces. También pueden salir mal por térmicas, inestabilidad o jitter por comportamiento agresivo de boost. Trata el tuning de BIOS como un despliegue por fases con burn-in y rollback.

8) ¿EPYC es solo “Ryzen para servidores”?

Comparten ADN arquitectónico, pero las piezas de servidor enfatizan canales de memoria, E/S, características de fiabilidad y validación de plataforma. Las consecuencias operativas (NUMA, layout PCIe, disciplina de firmware) son más pronunciadas.

9) ¿Cómo debo planificar capacidad al moverme a Ryzen/EPYC?

Empieza con caracterización de carga: CPU-bound vs memory-bound vs IO-bound. Luego benchmarkea en una plataforma de línea base y construye objetivos de reserva usando p99, no promedios.

10) ¿Cuál es el error operativo más común durante la migración?

Asumir que el planificador “hará lo correcto” con la localidad. A veces lo hará. A menudo no—especialmente bajo restricciones de contenedores y cargas mixtas.

Conclusión: próximos pasos que puedes hacer realmente

El regreso de Ryzen pareció repentino porque la industria miraba anuncios mientras AMD trabajaba años en arquitectura, estrategia de fabricación y madurez del ecosistema. Entonces la curva cruzó la línea donde compras, proveedores cloud y gestores de riesgo empresariales dijeron lo mismo: “Bien, podemos usar esto.” Ahí fue cuando pareció un éxito de la noche a la mañana.

Si gestionas sistemas de producción, la moraleja no es “compra Ryzen.” La moraleja es: no importes las suposiciones de ayer a la topología de hoy.

Próximos pasos prácticos

1. Establece la línea base de tu plataforma: elige BIOS, microcódigo, versiones de kernel; hazlos cumplir.
2. Ejecuta descubrimiento de topología en cada clase de hardware: captura lscpu y numactl; documenta layout NUMA para los ingenieros.
3. Construye una suite mínima de benchmarks: una prueba de latencia, una de throughput y una prueba mixta de IO; ejecútala en canarios tras cada cambio de firmware/kernel.
4. Decide si te importa la latencia de cola: si sí, implementa afinidad y políticas NUMA; si no, no pierdas tiempo en micro-optimizaciones.
5. Vigila a los asesinos silenciosos: throttling, errores ECC corregidos, núcleos calientes por IRQ y deriva de firmware.

Ryzen no ganó por ser mágico. Ganó por ser diseñado con la intención de enviarse a escala. Si lo operas de la misma manera—medido, estandarizado y consciente de la topología—también obtendrás el rendimiento “repentino”. Solo que no será repentino.