La CPU que compres hoy dictará en silencio tus próximos cinco años de tickets de incidentes: picos de latencia que no puedes reproducir,
pausas “misteriosas” del GC y ese trabajo por lotes que siempre se alarga justo antes de la reunión con el CFO.
La mayoría de los equipos todavía elige CPUs como eligen el café: lealtad a la marca, sensaciones y una captura de benchmark de un hilo de chat.
A Producción no le importan las sensaciones. A Producción le importan la latencia de cola, el comportamiento de la caché, la colocación NUMA y si
tu pila de almacenamiento está pidiendo ciclos que no presupuestaste. Si quieres cinco años de operaciones predecibles, compras según la carga de trabajo,
y lo demuestras con mediciones.
El principio central: carga de trabajo primero, logo al final
Una CPU no es un símbolo de estatus. Es un contrato: te comprometes con un equilibrio específico de núcleos, frecuencia,
caché, canales de memoria, lanes PCIe, límites de potencia y peculiaridades de plataforma. En cinco años, ese contrato o bien
mantendrá tus sistemas aburridos (el tipo bueno de aburrido) o convertirá cada conversación de escalado en una negociación presupuestaria.
Compra respondiendo estas preguntas con evidencia:
- ¿Qué se satura primero? ¿Ciclos de CPU, ancho de banda de memoria, caché, E/S o red?
- ¿Cuál es el SLO crítico? ¿Rendimiento, latencia p99, tiempo de finalización de trabajos o costo por unidad?
- ¿Cuál es el modelo de concurrencia? ¿Bucle caliente de hilo único, muchos hilos independientes o fork/join?
- ¿Qué tan “bursty” es? ¿Puedes aprovechar turbo/boost o vives a carga sostenida en todos los núcleos?
- ¿Qué más se ejecutará ahí? Sidecars, agentes, cifrado, compresión, scrubbing, backups, observabilidad.
Luego seleccionas una plataforma (CPU + placa base + memoria + valores por defecto del BIOS + potencia/refrigeración) que sirva esas respuestas.
No al revés.
Broma #1: Si tu proceso de selección de CPU empieza con “mi amigo dice”, tu próximo outage terminará con “mi amigo se equivocaba.”
Hechos rápidos e historia que realmente importan
Algunos puntos concretos—históricos y técnicos—que te ayudan a razonar por qué comprar CPUs modernas se siente raro:
- Las velocidades de reloj dejaron de escalar linealmente a mediados de los 2000 debido a densidad de potencia y calor; la industria giró fuertemente hacia multicore.
- Los relojes “Turbo”/boost cambiaron la matemática de aprovisionamiento: los picos cortos pueden lucir increíbles en benchmarks pero colapsan bajo carga sostenida en todos los núcleos.
- Hyper-threading/SMT no es “2x núcleos”; es un truco de utilización que ayuda a algunas cargas y perjudica a otras, especialmente bajo contención.
- NUMA ha sido el impuesto silencioso al rendimiento de servidores por décadas: la memoria local es rápida; la memoria remota es “rápida-ish hasta que no lo es”.
- Los tamaños de caché explotaron porque la memoria no siguió el ritmo; la latencia a DRAM sigue siendo cara, y muchas cargas accidentalmente quedan limitadas por latencia de memoria.
- AES-NI y extensiones similares hicieron que el cifrado sea lo suficientemente barato como para ser “activado por defecto”, desplazando los cuellos de botella a otros lugares.
- Las mitigaciones por especulación (post-2018) hicieron que detalles de microarquitectura importen operativamente; los niveles de parches pueden cambiar perfiles de rendimiento.
- El conteo de lanes PCIe se volvió una métrica de capacidad de primera clase a medida que NVMe, GPUs y smart NICs se volvieron normales en servidores “de propósito general”.
Nada de esto te dice qué marca comprar. Te dice por qué un benchmark de un solo número nunca describió tu futuro.
Formas de carga de trabajo: qué hace realmente tu CPU
1) Servicios críticos de latencia (p95/p99 vive aquí)
APIs web, autenticación, pujas de anuncios, datos de mercado, pagos: la métrica de negocio es la latencia de cola. Estas cargas a menudo tienen
pequeños bucles calientes, muchas ramas y fallos frecuentes de caché causados por grandes conjuntos de trabajo o churn del asignador.
Lo que quieres:
- Fuerte rendimiento por hilo (no solo pico turbo en un núcleo, sino sostenido bajo carga realista).
- Jerarquía de caché grande y efectiva; menos fallos de caché a escala vence a “más núcleos” para latencia de cola.
- Comportamiento de frecuencia predecible bajo límites térmicos y de potencia.
- Historia NUMA clara: fijar procesos críticos, mantener la memoria local, evitar charla entre sockets.
2) Cargas orientadas a rendimiento (batch, ETL, render, cómputo offline)
Si el tiempo de finalización importa más que la latencia por petición, a menudo puedes lanzar núcleos—hasta que el ancho de banda de memoria o E/S se convierta en pared.
Compiladores, granjas de build, trabajos ETL y algo de analítica adoran el paralelismo, pero solo si no pelean por canales de memoria.
Lo que quieres:
- Más núcleos físicos y suficiente ancho de banda de memoria para alimentarlos.
- Rendimiento sostenido en todos los núcleos bajo límites de potencia, no relojes de marketing efímeros.
- Suficiente PCIe para el almacenamiento y la red que inevitablemente añadirás a mitad de ciclo.
3) Hosts de virtualización y contenedores (la “mezcla”)
Hypervisores y nodos Kubernetes ejecutan un zoológico: algunas cosas son sensibles a latencia, otras están limitadas por CPU, y muchas son simplemente ruidosas.
Tu elección de CPU debe minimizar el radio de destrucción de ese ruido.
Lo que quieres:
- Suficientes núcleos para consolidación, pero no tantos que no puedas mantener la localidad por socket bajo control.
- Buena capacidad y canales de memoria; la sobreasignación de memoria se convierte en swap, y el swap en pánico existencial.
- Estabilidad de plataforma: valores por defecto del BIOS predecibles, microcódigo estable y comportamiento IOMMU limpio para passthrough si es necesario.
4) Servidores de almacenamiento (sí, la CPU importa mucho)
Las pilas de almacenamiento consumen CPU de maneras poco glamorosas: checksums, compresión, paridad RAID, cifrado, deduplicación (si tienes valor),
y operaciones de metadata. ZFS, Ceph, mdraid, LVM, dm-crypt—esto no es gratis.
Lo que quieres:
- Suficientes núcleos para trabajo en segundo plano (scrub, rebalanceo, compactación) mientras sirves E/S en primer plano.
- Fuerte subsistema de memoria; la E/S con mucho uso de metadata se transforma en bound por latencia de memoria.
- LANES y topología PCIe que coincidan con tu disposición de HBA/NVMe; “cabe en la ranura” no es lo mismo que “rinde”.
5) Cómputo especializado (transcoding, ML, crypto, compresión)
Estos son los más fáciles de acertar y los más fáciles de fallar. Acertar: medir las instrucciones usadas y elegir la mejor vía de acelerador
(GPU, Quick Sync, AVX-512, etc.). Fallar: asumir que la brillante extensión vectorial de tu CPU es una victoria garantizada.
Lo que quieres:
- Soporte de conjunto de instrucciones que tu software realmente usa (y a lo que está compilado).
- Térmicas y entrega de potencia que sostengan cargas vectoriales (pueden bajar mucho el reloj).
- Suficiente E/S para alimentar la bestia (NVMe para datasets, red rápida, etc.).
Rasgos de CPU que mueven la aguja (y los que no)
Núcleos vs frecuencia: deja de tratarlo como una elección binaria
El conteo de núcleos ayuda cuando tienes trabajo paralelo que puede mantenerse ocupado sin pelear por recursos compartidos.
La frecuencia ayuda cuando un pequeño número de hilos domina la latencia o cuando la contención de locks hace que “más hilos” sean mayormente más contención.
En cinco años, tu carga de trabajo derivará. Pero no suele pasar de “bucle caliente de un solo hilo” a “perfectamente paralelo”.
El enfoque práctico es clasificar tu carga por paralelismo efectivo:
- 1–4 hilos calientes importan más: prioriza fuerte rendimiento por núcleo y caché, y mantén la plataforma fría.
- 8–32 hilos útiles: balancea frecuencia y núcleos, vigila el ancho de banda de memoria.
- 64+ hilos útiles: los núcleos y los canales de memoria dominan; la topología y NUMA se vuelven el precipicio oculto.
La caché suele valer más de lo que presupuestas
Muchos servicios de producción son “limitados por CPU” solo porque están estancados en memoria. Si ves CPI alto, IPC bajo y muchos fallos de caché,
una CPU con más caché (o mejor comportamiento de caché) puede superar a una parte de mayor reloj. Esta es la forma menos sexy de ganar rendimiento y
la más repetible.
Canales de memoria, frecuencia y capacidad: el limitador silencioso
Si tu conjunto de trabajo no cabe en caché, ahora estás en el negocio de la memoria. Más núcleos sin suficiente ancho de banda de memoria se convierten en
“ocio caro”. Además, la capacidad de memoria es una característica de rendimiento: mantenerse fuera del swap y del thrash del page cache vence casi cualquier actualización de CPU.
NUMA y topología: el rendimiento que pierdes sin notarlo
En sistemas de doble socket (e incluso en algunos diseños complejos de un solo socket), la localidad de memoria importa. El acceso a memoria remota puede añadir latencia,
reducir ancho de banda e incrementar la varianza—especialmente visible en p99.
Si vas a multi-socket, presupuestar tiempo para:
- Planificación NUMA-aware (systemd CPUAffinity, Kubernetes CPU Manager, pinning de procesos de BD).
- Validar que tus NICs y dispositivos NVMe estén conectados al socket que ejecuta la carga.
- Medir con tráfico real, no con pruebas sintéticas que accidentalmente se mantienen dentro de un nodo NUMA.
LANES PCIe y topología de E/S: la trampa en servidores “de propósito general”
Puedes comprar una CPU con mucha capacidad de cómputo y luego ahogarla con E/S: muy pocos lanes PCIe, root complexes sobresuscritos,
o unidades NVMe colgadas de un switch que comparte ancho de banda de formas que no modelaste. En cinco años, añadirás NICs, más NVMe,
tal vez una GPU, tal vez una DPU. Elige una plataforma con margen.
Límites de potencia y refrigeración: el rendimiento sostenido es el único rendimiento
Las CPUs no “tienen” una frecuencia; la negocian con la física. Si tu chasis, ventiladores o temperaturas de entrada del datacenter son marginales,
tu SKU caro se convierte en uno más barato bajo carga. Esto aparece como “benchmarks extrañamente inconsistentes” y luego como “¿por qué la latencia empeoró?”
La marca no es una estrategia
Compra la pieza que gana en tus métricas, en tu pila de compilador/tiempo de ejecución, en tu envelope de potencia, con tu cadena de suministro. Luego valida.
Eso es todo. El logo es para la factura.
Broma #2: La mejor CPU es la que no te obliga a aprender un nuevo portal de proveedor a las 3 a.m.
Planificación a cinco años: qué cambia y qué no
Cinco años es tiempo suficiente para que tu carga evolucione y corto suficiente para que sigas ejecutando algún legado vergonzoso.
La selección de CPU debe sobrevivir:
- Actualizaciones de software que cambien características de rendimiento (nuevo comportamiento JIT, nuevos valores por defecto de motores de almacenamiento, nuevo scheduler del kernel).
- Regímenes de parches de seguridad que pueden afectar el rendimiento microarquitectónico.
- Nuevos agentes de observabilidad que “solo necesitan un poco de CPU.” Todos lo hacen.
- Crecimiento en el tamaño de datasets que convierta cargas cache-friendly en cargas limitadas por latencia de memoria.
- Deriva de plataforma: actualizaciones de BIOS, cambios de microcódigo y características de firmware como valores por defecto de gestión de potencia.
Compra margen en la dimensión correcta
El margen no es “50% más núcleos.” El margen es:
- Capacidad de memoria para crecer sin hacer swap.
- Ancho de banda de memoria para que los núcleos añadidos no se queden estancados.
- Lanes PCIe para expansión sin sobresuscripción de E/S.
- Margen térmico para que la carga sostenida no baje el reloj.
- Una familia de SKU que puedas seguir adquiriendo en el año 3 sin rogar.
Prefiere plataformas aburridas cuando la disponibilidad es el producto
Las plataformas de vanguardia están bien cuando tienes un laboratorio, capacidad de sobra y un plan de rollback. Si gestionas un equipo austero,
prefiere la combinación CPU/plataforma con firmware predecible, soporte de kernel maduro y compatibilidad conocida con NIC/HBA.
No te pagan por novedad.
Una cita, porque sigue siendo el mejor consejo de ops
La esperanza no es una estrategia.
— James Cameron
Se aplica de manera vergonzosamente buena a la planificación de capacidad y compra de CPU.
Tres microhistorias corporativas desde las trincheras
Microhistoria #1: El incidente causado por una suposición equivocada
Una compañía SaaS mediana migró su capa de API a servidores nuevos que parecían perfectos en papel: más núcleos, generación más nueva,
mejores puntuaciones sintéticas. La carga era un servicio Java con una ruta de autenticación caliente y un montón de pequeñas asignaciones.
Había sido estable por años.
En días, la latencia p99 empezó a dispararse. No la latencia promedio. No la utilización de CPU. Solo p99, en ráfagas que coincidían con picos de tráfico.
El equipo asumió ajuste de GC. Ajustaron tamaños de heap, cambiaron recolectores, hicieron roll forward y back. Los picos persistieron.
La suposición equivocada fue que “más núcleos” mejora automáticamente la latencia de cola. En realidad, la nueva plataforma tenía una topología NUMA diferente,
y su scheduler de contenedores colocaba felizmente el proceso en un socket mientras las asignaciones de memoria venían de otro. Añade un poco de contención de locks
y obtienes una lotería de latencia.
La solución no fue heroica. Fijaron conjuntos de CPU y la política de memoria para los pods críticos de latencia, ajustaron la afinidad de IRQ para que las colas NIC fueran
locales al cómputo y validaron con contadores perf. Los picos p99 desaparecieron. La CPU no era mala. La suposición sí.
Microhistoria #2: La optimización que salió mal
Un equipo de almacenamiento que ejecutaba un objeto store respaldado por ZFS decidió que eran “pesados en CPU”, basándose en top que mostraba mucho tiempo en system durante el ingest pico.
Alguien propuso habilitar compresión agresiva en todas partes y confiar en “CPUs modernas” para hacerlo gratis. Lo desplegaron gradualmente.
El ingest mejoró inicialmente. El dashboard se veía mejor. Luego la ventana semanal de scrub empezó a solaparse con horario laboral porque los scrubs tardaban más.
La latencia de lecturas se volvió más ruidosa y algunos clientes se quejaron de timeouts durante mantenimientos en segundo plano.
La compresión no era la villana; la compresión sin límites sí lo era. El sistema ahora hacía malabares con compresión en primer plano, checksums de scrub en segundo plano
e interrupciones de red en los mismos núcleos. Accidentalmente movieron el cuello de botella del disco a la programación de CPU y presión de caché.
El rollback fue parcial: mantuvieron compresión para datos fríos y ajustaron recordsize y nivel de compresión para buckets calientes.
Más importante, reservaron núcleos para mantenimiento de almacenamiento e aislaron el manejo de interrupciones. El rendimiento volvió y las ventanas de scrub se
volvieron predecibles otra vez. La lección: “La CPU es barata” es una frase peligrosa cuando también necesitas mantenimiento determinista.
Microhistoria #3: La práctica aburrida pero correcta que salvó el día
Una firma de servicios financieros tenía una costumbre que parecía dolorosamente conservadora: antes de aprobar cualquier nueva plataforma de CPU,
corrían un canario en producción durante una semana con tráfico espejado y puertas SLO estrictas. Procurement lo odiaba. Los ingenieros a veces refunfuñaban.
Lentificaba la “innovación”. También prevenía outages.
Durante un ciclo de renovación, un modelo nuevo de servidor pasó benchmarks básicos y pruebas unitarias pero mostró pérdidas de paquetes intermitentes bajo carga sostenida.
Las pérdidas eran lo bastante raras como para que pruebas cortas las perdieran. El canario las atrapó porque corrió lo suficiente para golpear las térmicas reales y
los patrones reales de colas NIC.
Trabajaron con el proveedor y encontraron una interacción firmware + BIOS power management que causaba breves picos de latencia en el manejo de interrupciones.
Una actualización de firmware y un cambio de ajuste en BIOS lo resolvieron. Ningún cliente lo vio. No fue necesaria una revisión de incidentes.
La práctica no era glamorosa: canarios largos, criterios de aceptación aburridos y la negativa a confiar en un solo benchmark.
Así es como se ve “reliability engineering” cuando funciona.
Tareas prácticas: comandos, salidas y decisiones (12+)
Estas son tareas de campo que puedes ejecutar en un servidor candidato (o en uno existente) para entender qué tipo de CPU necesitas.
Cada tarea incluye: el comando, qué significa la salida y la decisión que tomas a partir de ello.
Task 1: Identify CPU model, cores, threads, and sockets
cr0x@server:~$ lscpu
Architecture: x86_64
CPU(s): 64
Thread(s) per core: 2
Core(s) per socket: 32
Socket(s): 1
Model name: AMD EPYC 7543 32-Core Processor
NUMA node(s): 1
L3 cache: 256 MiB
Qué significa: Ahora conoces tu línea base: 32 núcleos físicos, SMT habilitado, socket único y gran caché L3.
Decisión: Si necesitas latencia predecible, socket único a menudo simplifica NUMA. Si tu carga es orientada a rendimiento, 32 núcleos pueden ser perfectos—o estar hambrientos de ancho de banda de memoria. No adivines; mide.
Task 2: Check CPU frequency behavior under load (governor and scaling)
cr0x@server:~$ cpupower frequency-info
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
available cpufreq governors: performance powersave
current policy: frequency should be within 1500 MHz and 3700 MHz.
The governor "performance" may decide which speed to use
current CPU frequency: 3692 MHz (asserted by call to hardware)
Qué significa: Probablemente no estás atascado en un governor de baja potencia. Hay margen de frecuencia hasta ~3.7 GHz.
Decisión: Para nodos críticos de latencia, usa performance y valida relojes sostenidos bajo carga real. Si la frecuencia colapsa bajo carga, necesitas mejor refrigeración/límites de potencia o un SKU diferente.
Task 3: See if you’re CPU-saturated or just “busy”
cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server) 01/12/2026 _x86_64_ (64 CPU)
12:00:01 PM CPU %usr %nice %sys %iowait %irq %soft %steal %idle
12:00:02 PM all 62.10 0.00 10.40 0.20 0.10 1.30 0.00 25.90
12:00:02 PM 0 95.00 0.00 4.00 0.00 0.00 0.00 0.00 1.00
12:00:02 PM 1 10.00 0.00 1.00 0.00 0.00 0.00 0.00 89.00
Qué significa: Hay margen global, pero CPU0 está caliente. Eso es un hotspot de scheduling o interrupciones, no “necesitar más núcleos”.
Decisión: Antes de comprar una CPU más grande, arregla el pinning/afinidad de IRQ. Si %idle está cercano a cero en CPUs y la carga escala con la demanda, quizá necesites más cómputo.
Task 4: Check run queue pressure (are you waiting on CPU?)
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
8 0 0 802312 11232 9212440 0 0 0 12 5821 9902 64 11 25 0 0
12 0 0 801900 11232 9212600 0 0 0 0 6001 11022 72 12 16 0 0
Qué significa: r son 8–12 tareas ejecutables. Si eso está consistentemente por encima del conteo de núcleos, estás saturado de CPU. Aquí está por debajo de 64 hilos pero podría estar por encima de núcleos físicos en sistemas más pequeños.
Decisión: Si r está consistentemente alto y la latencia aumenta, necesitas más núcleos o mejor paralelismo. Si wa sube, estás bloqueado en I/O, no en CPU.
Task 5: Determine if memory bandwidth/latency is the limit
cr0x@server:~$ perf stat -a -e cycles,instructions,cache-misses,LLC-load-misses -I 1000 sleep 3
# time counts unit events
1.000349290 3,210,442,991 cycles
1.000349290 2,120,112,884 instructions
1.000349290 45,332,100 cache-misses
1.000349290 12,501,883 LLC-load-misses
2.000719401 3,188,102,112 cycles
2.000719401 2,098,554,001 instructions
2.000719401 46,110,220 cache-misses
2.000719401 12,980,004 LLC-load-misses
Qué significa: Instructions per cycle está alrededor de 0.65 (2.1B / 3.2B), y los fallos de LLC son significativos. Eso apunta a stalls por memoria.
Decisión: Si tu servicio está pesado en stalls de memoria, elige CPUs con mejor comportamiento de caché e invierte en canales/velocidad de memoria. “Más GHz” no arreglará fallos de caché.
Task 6: Check NUMA layout and distances
cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-31
node 0 size: 257837 MB
node 0 free: 210112 MB
node 1 cpus: 32-63
node 1 size: 257838 MB
node 1 free: 211004 MB
node distances:
node 0 1
0: 10 21
1: 21 10
Qué significa: Dos nodos NUMA con acceso remoto que cuesta ~2x local (distancia 21 vs 10). Eso es relativamente normal, pero se notará en p99 si lo ignoras.
Decisión: Si ejecutas servicios sensibles a latencia, prefiere socket único o aplica localidad NUMA. Si debes ir dual-socket, planifica pinning y política de memoria desde el día uno.
Task 7: Map PCIe devices to NUMA nodes (NICs, NVMe, HBAs)
cr0x@server:~$ lspci -vv | grep -E "Ethernet|Non-Volatile|NUMA"
3b:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
NUMA node: 1
41:00.0 Ethernet controller: Mellanox Technologies MT27800 Family [ConnectX-5]
NUMA node: 0
Qué significa: Tu NIC es local al nodo 0, NVMe al nodo 1. Si tu ruta de E/S cruza sockets, acabas de comprarte varianza de latencia.
Decisión: Alinea cargas con sus dispositivos de E/S (fija cómputo cerca de NIC/NVMe) o reubica hardware. Para compras nuevas, elige plataformas con suficientes lanes para evitar ubicaciones incómodas.
Task 8: Identify interrupt hotspots (often mistaken for “CPU needs upgrade”)
cr0x@server:~$ cat /proc/interrupts | head -n 8
CPU0 CPU1 CPU2 CPU3
24: 99211231 0 0 0 PCI-MSI 524288-edge mlx5_comp0@pci:0000:41:00.0
25: 0 98122010 0 0 PCI-MSI 524289-edge mlx5_comp1@pci:0000:41:00.0
26: 0 0 99100110 0 PCI-MSI 524290-edge mlx5_comp2@pci:0000:41:00.0
27: 0 0 0 98911220 PCI-MSI 524291-edge mlx5_comp3@pci:0000:41:00.0
Qué significa: Las interrupciones están bien distribuidas aquí; en muchos sistemas no lo están y una CPU recibe la paliza.
Decisión: Si las interrupciones se acumulan en una CPU, arregla la afinidad de IRQ y los ajustes de colas antes de cambiar CPUs. La latencia de cola mejora dramáticamente con distribución correcta de interrupciones.
Task 9: Check for throttling and thermal limits
cr0x@server:~$ dmesg | grep -iE "thrott|thermal|powercap" | tail -n 5
[ 8921.112233] intel_rapl_common: Found RAPL domain package
[ 9122.445566] CPU0: Core temperature above threshold, cpu clock throttled (total events = 3)
[ 9122.445700] CPU0: Package temperature/speed normal
Qué significa: Estás térmicamente limitando ocasionalmente. Eso es variabilidad de rendimiento que sentirás en p99.
Decisión: Si el throttling aparece bajo carga normal, arregla refrigeración, curvas de ventilador, contacto del disipador o límites de potencia. Si no puedes, no compres el SKU top-bin que solo rinde en un laboratorio ideal.
Task 10: Validate virtualization overhead and steal time
cr0x@server:~$ mpstat 1 3 | tail -n 3
12:10:02 PM all 40.00 0.00 8.00 0.00 0.00 0.50 7.50 44.00
12:10:03 PM all 42.00 0.00 9.00 0.00 0.00 0.40 8.20 40.40
12:10:04 PM all 41.50 0.00 8.80 0.00 0.00 0.60 8.10 41.00
Qué significa: %steal alrededor de 8% indica que tu VM está esperando porque el hypervisor está sobresuscrito o hay vecinos ruidosos.
Decisión: No “arregles” el tiempo de steal actualizando la CPU del guest. Arregla la sobresuscripción del host, reserva CPU o mueve cargas. Para compras, asegúrate de que los hosts tengan suficientes núcleos reales para los objetivos de consolidación.
Task 11: Determine if storage is stealing your cycles (ZFS example)
cr0x@server:~$ zpool iostat -v 1 3
capacity operations bandwidth
pool alloc free read write read write
tank 7.21T 3.12T 980 4.20K 112M 610M
raidz2 7.21T 3.12T 980 4.20K 112M 610M
nvme0n1 - - 120 520 14.0M 72.0M
nvme1n1 - - 118 525 13.8M 72.5M
nvme2n1 - - 121 515 14.2M 71.2M
nvme3n1 - - 119 518 13.9M 71.8M
Qué significa: Estás empujando 610 MB/s de escrituras con 4.2K ops/s. Si la CPU también está alta, checksumming/compresión/paridad puede ser el limitador, no las unidades.
Decisión: Para servidores de almacenamiento, favorece CPUs con suficientes núcleos para mantenimiento y servicios de datos, y asegura memoria abundante. Si el throughput de escritura se platea con la CPU al máximo, necesitas más CPU o distintas elecciones de RAID/compresión.
Task 12: Measure network processing load (softirq pressure)
cr0x@server:~$ sar -n DEV 1 3
Linux 6.5.0 (server) 01/12/2026 _x86_64_ (64 CPU)
12:15:01 PM IFACE rxpck/s txpck/s rxkB/s txkB/s
12:15:02 PM eth0 120000 118500 980000 910000
12:15:03 PM eth0 121200 119100 990500 915200
Qué significa: Tasas de paquetes muy altas. Eso es trabajo de CPU (softirq, interrupciones), no solo “ancho de banda de red”.
Decisión: Si la tasa de paquetes es alta, elige CPUs con fuerte rendimiento por núcleo y asegura la afinidad de colas/IRQ de la NIC. A veces menos núcleos más rápidos vencen a más núcleos más lentos para cargas con muchos paquetes.
Task 13: Check context switching and scheduler churn
cr0x@server:~$ pidstat -w 1 3
Linux 6.5.0 (server) 01/12/2026 _x86_64_ (64 CPU)
12:18:01 PM UID PID cswch/s nvcswch/s Command
12:18:02 PM 0 1221 1200.00 300.00 kubelet
12:18:02 PM 999 3456 22000.00 9000.00 java
Qué significa: Altos switches voluntarios y no voluntarios. Eso suele ser contención de locks, demasiados hilos o scheduling ruidoso.
Decisión: Antes de añadir núcleos, reduce conteos de hilos, afina runtimes o aísla cargas. Si no puedes, prefiere mayor rendimiento por núcleo y menos migraciones cross-NUMA.
Task 14: Confirm kernel sees correct mitigations (performance can shift)
cr0x@server:~$ grep -E "Mitigation|Vulnerable" /sys/devices/system/cpu/vulnerabilities/* | head
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpolines; IBPB: conditional; STIBP: disabled; RSB filling
Qué significa: No puedes ignorar las mitigaciones de seguridad; influyen en cargas con muchas syscalls y cambios de contexto.
Decisión: Para servicios con muchas syscalls, mide rendimiento con las mitigaciones reales que ejecutarás en producción. No hagas benchmarks con una configuración de kernel de laboratorio que no vas a desplegar.
Manual de diagnóstico rápido: encuentra el cuello de botella pronto
Cuando algo está lento y todos empiezan a discutir sobre CPUs, necesitas un manual corto que corte el ruido.
Esta secuencia está diseñada para triage en producción: mínima herramienta, máxima señal.
Primero: decide si estás limitado por CPU, E/S o esperando otra cosa
- Ejecuta
mpstatpara ver idle, iowait y steal time. - Ejecuta
vmstatpara ver la cola ejecutablery el waitwa. - Revisa load average con
uptime, pero no lo trates como verdad—trátalo como humo.
Si %idle está bajo y r es alto, plausiblemente estás limitado por CPU.
Si %iowait está alto o aparecen procesos bloqueados, estás limitado por E/S.
Si %steal está alto en VMs, el hypervisor te está robando.
Segundo: clasifica el dolor de CPU (cómputo vs memoria vs scheduler)
- Usa
perf statpara IPC y fallos de caché. IPC bajo + muchos fallos sugiere stalls de memoria. - Usa
pidstat -wpara cambios de contexto. Muchos switches sugieren contención o demasiados hilos. - Revisa NUMA con
numactl --hardwarey la colocación de dispositivos conlspci.
Tercero: busca los pies de plomo específicos de la plataforma
- Throttling en
dmesg(térmico/powercap). - Desequilibrio de interrupciones en
/proc/interrupts. - Mismatch de governor de frecuencia en
cpupower frequency-info. - Tiempo de steal en virtualización: arregla el dimensionamiento del host, no las CPUs guest.
Cuarto: decide qué cambiar
- Si está CPU-saturated y escala con la demanda: añade núcleos o divide el servicio.
- Si está memory-stalled: prioriza caché/canales de memoria; considera menos núcleos más rápidos sobre muchos más lentos.
- Si es NUMA/topología: pin, alinea dispositivos o prefiere socket único para niveles de latencia.
- Si es térmico/potencia: arregla refrigeración o deja de comprar SKUs que no puedes sostener.
Errores comunes: síntomas → causa raíz → solución
1) Síntoma: la latencia p99 empeora después de la “actualización”
Causa raíz: Acceso remoto a memoria NUMA, IRQs en el socket equivocado o inestabilidad de frecuencia bajo carga.
Solución: Fija procesos y memoria, alinea NIC/NVMe al mismo nodo NUMA, establece el governor apropiado y verifica que no haya eventos de throttling.
2) Síntoma: uso de CPU es alto, pero el rendimiento no mejora con más núcleos
Causa raíz: Límite de ancho de banda de memoria, contención por locks o thrash de caché. Más núcleos aumentan contención y stalls.
Solución: Mide IPC y fallos de caché, reduce conteos de hilos, shardea o particiona trabajo, o elige una CPU con mejor caché/subsistema de memoria en lugar de más núcleos.
3) Síntoma: picos “aleatorios” durante tráfico pico
Causa raíz: Tormentas de interrupciones, vecinos ruidosos (steal), tareas en segundo plano (scrub, compactación), o throttling térmico.
Solución: Aísla núcleos para IRQs y trabajo en segundo plano, reserva CPU, corre canarios largos y audita térmicas bajo carga sostenida.
4) Síntoma: el load average es alto, pero la CPU no está ocupada
Causa raíz: Tareas bloqueadas en E/S, latencia de almacenamiento o esperas del kernel; el load average cuenta tareas ejecutables e ininterrumpibles.
Solución: Revisa %iowait, estadísticas de almacenamiento y procesos bloqueados. Mejora almacenamiento o arregla la ruta de E/S; no compres CPUs para compensar discos lentos.
5) Síntoma: el servidor de almacenamiento no alcanza velocidades NVMe esperadas
Causa raíz: Sobresuscripción de topología PCIe, ranura mal cableada, root complex compartido o overhead de CPU en checksums/paridad/cifrado.
Solución: Valida la colocación PCIe, asegura suficientes lanes, mide el costo de CPU de las features de almacenamiento y reserva CPU para mantenimiento en segundo plano.
6) Síntoma: el benchmark luce bien, producción luce mediocre
Causa raíz: El benchmark usa un solo hilo, cabe en caché o corre 30 segundos. Producción corre días y falla caché todo el tiempo.
Solución: Haz benchmarks con tamaños de dataset, concurrencia y duración reales. Usa tráfico canario y puertas SLO.
7) Síntoma: el rendimiento cambia después de actualizar firmware/microcódigo
Causa raíz: Cambiaron valores por defecto de gestión de potencia, el comportamiento de mitigaciones cambió o las interacciones con el scheduler se movieron.
Solución: Trata el firmware como una release: prueba, mide, fija ajustes de BIOS y documenta la configuración “conocida buena” para tu flota.
Listas de verificación / plan paso a paso
Pasos: elegir la CPU correcta para un horizonte de 5 años
- Escribe la mezcla real de cargas. Incluye tareas en segundo plano (backups, scrubs, compactación, agentes de observabilidad).
- Define métricas de éxito. Rendimiento, latencia p99, costo por petición, tiempo de finalización. Elige dos, no diez.
- Captura evidencia del cuello de botella actual. Usa
mpstat,vmstat,perf stat, NUMA y mapeo de E/S. - Clasifica la forma de la carga. Crítica de latencia vs throughput vs virtualización mixta vs orientada a almacenamiento.
- Elige restricciones de plataforma primero. Socket único vs dual, canales/capacidad de memoria, lanes PCIe, plan de NIC/HBA, potencia y refrigeración del rack.
- Selecciona 2–3 SKUs candidatos. Uno “seguro”, uno “de rendimiento”, uno “optimizado por costo”.
- Corre benchmarks realistas. Mismo kernel, mismas mitigaciones, mismo tamaño de dataset, misma duración de ejecución.
- Haz un canario en producción. Tráfico espejado, corre lo bastante para golpear térmicas y ciclos de mantenimiento.
- Fija ajustes de BIOS y firmware. Documenta. Hazlos reproducibles en la flota.
- Decide con una justificación escrita. Incluye qué optimizas, qué sacrificas y la evidencia.
Lista: no te sorprendan en el año 3
- Ranuras de memoria libres para expansión, no totalmente pobladas el primer día a menos que sea necesario.
- Margen de lanes PCIe para añadir NVMe o NICs más rápidas más adelante.
- Margen de refrigeración probado a carga sostenida en tu chasis real.
- Capacidad sobrante para mantenimiento en segundo plano (scrubs, compactación, indexación, backups).
- Chequeo de realidad de la cadena de suministro: ¿puedes comprar la misma plataforma más tarde?
- Listo el tooling operativo: ¿puedes observar utilización por núcleo, throttling y problemas NUMA?
Lista: ajustes de plataforma para estandarizar (para que el rendimiento no derive)
- Governor de CPU / perfil de potencia
- Política SMT (on/off) por clase de carga
- Política de balanceo NUMA y estrategia de pinning
- Afinidad de IRQ y configuración de colas NIC
- Estrategia de fijado de versión de microcódigo y firmware
- Política de mitigaciones del kernel consistente con la postura de seguridad
Preguntas frecuentes
1) ¿Debería comprar el mayor conteo de núcleos que pueda para “prepararme para el futuro”?
No. Compra la mezcla correcta. Alto conteo de núcleos sin ancho de banda de memoria y efectividad de caché suele empeorar p99 y aumentar costos.
Prepararse para el futuro suele ser capacidad de memoria + margen PCIe + rendimiento sostenido predecible.
2) ¿Es siempre mejor un socket único que dual-socket?
Para capas críticas de latencia, socket único suele ser más fácil de ejecutar bien porque reduces la complejidad NUMA.
Para cómputo orientado a throughput o necesidades masivas de memoria, dual-socket puede ser correcto—si te comprometes a operaciones NUMA-aware.
3) ¿Quiero SMT/Hyper-Threading habilitado?
Depende. SMT puede mejorar el throughput para algunas cargas mixtas. También puede incrementar contención y jitter para servicios sensibles a la latencia de cola.
Prueba ambos modos con carga realista; elige por rol de cluster, no como regla universal.
4) ¿Cómo sé si mi carga está limitada por latencia de memoria?
IPC bajo, muchos fallos de caché/LLC y escalado débil con más núcleos son signos clásicos. Usa perf stat para chequear instructions vs cycles y fallos de caché,
y valida con tamaños de dataset que coincidan con producción.
5) ¿Son inútiles los benchmarks sintéticos?
No inútiles—peligrosos cuando se usan solos. Sirven para detectar regresiones obvias y defectos de hardware.
Son malos predictores de latencia de cola, efectos NUMA, problemas de topología de E/S y comportamiento térmico sostenido.
6) ¿Qué importa más para hosts de virtualización: núcleos o frecuencia?
Ambos, pero no ignores la memoria. La consolidación necesita núcleos; inquilinos ruidosos y overhead de red/almacenamiento suelen castigar bajo rendimiento por núcleo.
Si ejecutas cargas mixtas, normalmente quieres una CPU balanceada más buena capacidad y ancho de banda de memoria.
7) Si usamos ZFS o Ceph, ¿debemos priorizar la CPU más de lo habitual?
Sí. Las features de almacenamiento modernas son features de CPU: checksums, compresión, cifrado, paridad y mantenimiento en segundo plano.
También prioriza memoria (ARC, metadata, caching) y topología PCIe para que tus unidades rápidas no se conviertan en cuello de botella aguas arriba.
8) ¿Cuándo es racional pagar por partes “top bin”?
Cuando estás limitado por latencia en unos pocos hilos calientes y puedes mantener la CPU lo bastante fría para sostener relojes altos.
Si tu chasis o datacenter no pueden sostenerlo, la prima se dona mayormente a la física.
9) ¿Cómo pensar en consumo de energía a cinco años?
La energía no es solo costo; también es estabilidad de rendimiento. Una plataforma siempre al borde de potencia/térmicas será ruidosa.
Elige una CPU que entregue el rendimiento necesario dentro de tu realidad de potencia y refrigeración en rack, no un folleto.
10) ¿Cuál es el mayor “indicio” de que estamos eligiendo CPUs por logo?
Cuando la evaluación termina en “este benchmark es más alto”, sin aclarar qué métrica estás optimizando (p99 vs throughput) y sin un plan canario.
Si no puedes describir tu cuello de botella con mediciones, estás comprando emocionalmente.
Próximos pasos que puedes hacer esta semana
Si quieres una decisión de CPU que no lamentes en cinco años, haz el trabajo poco glamuroso ahora:
- Perfila un host representativo usando los comandos arriba y anota qué te está limitando realmente.
- Decide tu métrica principal: latencia p99, throughput o costo por unidad. Elige una primaria y una secundaria.
- Construye una lista candidata de 2–3 CPUs e incluye restricciones de plataforma: canales de memoria, lanes PCIe y refrigeración.
- Ejecuta una prueba larga (horas, no minutos). Incluye mantenimiento en segundo plano (scrub, backups, compactación) en la ventana de prueba.
- Canary en producción con tráfico espejado y un switch de rollback. Aburrido, sí. Efectivo, absolutamente.
- Documenta la decisión con evidencia: qué mediste, qué elegiste y qué no optimizaste intencionalmente.
El objetivo no es elegir la “mejor” CPU. El objetivo es elegir la CPU que haga que tus cargas específicas sean aburridas de operar, durante mucho tiempo.