Intel Tick-Tock: la estrategia que funcionó… hasta que dejó de hacerlo

Tick-tock en un párrafo

Tick-tock de Intel era un ritmo de desarrollo de producto: un “tick” significaba una reducción del nodo de fabricación (mismo diseño básico, transistores más pequeños) y un “tock” significaba una nueva microarquitectura (nuevo diseño) sobre un proceso probado. Aproximadamente cada año, obtenías o una reducción o un rediseño. Para los clientes eso creó la ilusión de un metrónomo: ganancias previsibles de rendimiento por vatio, ciclos de renovación predecibles, calendarios de depreciación previsibles, planes de personal predecibles, predecible todo. Esa predictibilidad fue real—hasta que dejó de serlo.

Por qué a operaciones le encantaba tick-tock (y por qué eso era peligroso)

Desde la silla de un SRE, tick-tock era más que marketing. Era un primitivo de planificación. Podías construir modelos trimestrales de capacidad con la suposición “la CPU gen N+1 entrega X% más rendimiento con Y% menos consumo”, y luego convertir eso en recuentos de racks y envelopes de potencia. Podías programar migraciones, burn-in de hardware y renovaciones de flota como si estuvieras dirigiendo una fábrica.

El peligro: la planificación basada en cadencia tiende a convertirse en planificación basada en fe. Cuando construyes una dependencia de negocio en el calendario de un proveedor, conviertes tus propias operaciones en un producto derivado. Eso está bien cuando el proveedor cumple la cadencia. Cuando se retrasan, tu tasa de incidentes se vuelve función de la litografía de alguien más.

Tick-tock también fomentó un tipo específico de mal hábito: posponer el trabajo duro. “Lo arreglaremos en la siguiente renovación” es un narcótico operativo. Suena responsable—¿para qué ajustar o rediseñar ahora si las CPUs del año próximo te salvarán? Luego el año siguiente no llega a tiempo, y te quedas con una carga de trabajo que nunca aprendió a comportarse.

Una de las razones por las que el modelo funcionó tanto tiempo es que alineaba incentivos. Intel tenía una historia clara que contar. Los OEM obtenían lanzamientos de producto previsibles. Las empresas tenían un calendario sobre el cual colgar presupuestos. Todo el ecosistema convergía en el “mejoramiento generacional” como la solución por defecto a problemas de rendimiento.

Broma #1: La era tick-tock era como tener un metrónomo para tu presupuesto. Luego la física entró y lo desenchufó.

Datos interesantes y contexto histórico (cosas que la gente olvida)

• Tick-tock empezó como una herramienta de disciplina. No fue solo un eslogan; era una forma de forzar el riesgo alternado: riesgo de fabricación en un ciclo, riesgo de diseño en el siguiente.
• Se extendió más allá de tick-tock. Intel finalmente pasó a un modelo “proceso–arquitectura–optimización”, reconociendo que la simple alternancia no se sostenía.
• “14nm” se convirtió en más de una generación. Varias familias de CPU y refrescos vivieron en 14nm más tiempo del esperado, estirando lo que “nueva generación” significaba operativamente.
• Los retrasos de 10nm no fueron solo deslices de calendario. Reflejaban desafíos de rendimiento y complejidad vinculados al escalado, multi-patroneo y alcanzar objetivos simultáneamente (densidad, frecuencia, fuga).
• Las ganancias de IPC nunca estuvieron garantizadas. Los cambios de microarquitectura pueden intercambiar rendimiento por hilo por eficiencia, endurecimiento de seguridad o más núcleos—útil, pero no siempre lo que tu carga necesita.
• La potencia se convirtió en el techo antes que el cómputo. Para muchos centros de datos, el amperaje y la refrigeración limitaron el rendimiento real más que las “especificaciones de CPU”. Tick-tock no anuló la termodinámica.
• Las mitigaciones de seguridad cambiaron la línea base de rendimiento. Después de 2018, las mitigaciones y actualizaciones de microcódigo complicaron las comparaciones entre generaciones; algunas cargas pagaron sobrecostes reales.
• Los competidores mejoraron mientras Intel tropezaba. El resurgimiento de AMD significó que el calendario de Intel dejó de ser el calendario de toda la industria.
• El paralelismo en software se volvió el multiplicador. A medida que las mejoras por núcleo se desaceleraron, el rendimiento total dependió cada vez más del número de núcleos y de la capacidad del software para escalar—a menudo la parte más difícil.

Dónde se rompió: proceso, física y ejecución

La verdad incómoda: “reducir” dejó de ser la mitad fácil

En los primeros años de tick-tock, las reducciones de proceso ofrecían un paquete bastante fiable: menor consumo con rendimiento similar, o más rendimiento con consumo similar. Eso no es magia; es geometría y mejoras de fuga más mejores materiales y diseño. Pero a medida que los nodos fueron más pequeños, todo se volvió más difícil a la vez: patronado, variabilidad, resistencia de interconexión y el coste económico de perseguir defectos mínimos en obleas enormes.

A la gente de operaciones le encanta “nodo más pequeño” porque suena a comida gratis. Nunca lo fue. La comida la pagaba una herramienta de fabricación cada vez más compleja, rendimientos cada vez más frágiles y mucha heroicidad de ingeniería. Cuando esa tubería de heroicidades se atasca—por complejidad, por madurez de herramientas, por problemas de integración—tu cadencia falla.

La falla de la cadencia cambia los incentivos de todos los downstream

Cuando un proveedor retrasa un nodo de proceso, los clientes se ven forzados a tomar decisiones raras:

• ¿Compras la generación “actual” otra vez, aunque planeabas saltártela?
• ¿Extiendes la vida del equipo antiguo, incrementando fallos y trabajo operativo?
• ¿Cambias de proveedor o plataforma, asumiendo trabajo de calificación y riesgo?
• ¿Rearquitectas la carga para necesitar menos CPU?

Tick-tock enmascaró estos trade-offs. Su declive los expuso.

El impulso de microarquitectura depende de la carga de trabajo, y siempre fue así

Otra razón por la que la narrativa tick-tock eventualmente se agrietó: la idea de que “la próxima generación es 20% más rápida” es como mucho una mediana en benchmarks sintéticos o curados. En producción, tu rendimiento puede estar anclado a un único canal de memoria, un punto caliente de contención de locks, una elección del scheduler del kernel, la profundidad de la cola de almacenamiento o la moderación de interrupciones del NIC. Las mejoras de microarquitectura no arreglan la mala concurrencia. Solo hacen que falle más rápido.

La “optimización” se volvió una línea de producto porque importaba el time-to-market

Una vez que los deslices de cadencia se normalizaron, Intel—como cualquier gran organización de ingeniería—tuvo que enviar algo. Eso a menudo significa optimización iterativa sobre un proceso estable en lugar de una alternancia limpia de tick-tock. Operativamente, eso cambia cómo calificas nuevos servidores. Una “renovación” puede ser una mejora modesta, no un gran salto. Tu plan de pruebas debe ser lo bastante sensible para detectar regresiones pequeñas pero significativas: jitter, latencia de cola, comportamiento de turbo bajo límites de cgroup o anomalías de perf bajo mitigaciones.

Idea parafraseada (atribuida a James Hamilton): “La fiabilidad viene de diseñar sistemas que toleren fallos, no de asumir que los componentes o los calendarios no fallarán.”

Cómo el declive de tick-tock cambió SRE y la planificación de capacidad

La planificación de capacidad cambió de “predecir mejora” a “diseñar para la incertidumbre”

En la era cómoda de tick-tock, podías tratar la mejora de CPU como interés en una cuenta de ahorros. En el mundo posterior a la cadencia, la mejora es irregular. Puedes obtener un salto significativo por conteo de núcleos en un ciclo, y luego solo ganancias marginales en el siguiente. O puedes obtener un aumento que se borra por límites de potencia y políticas de turbo. Así que la planificación moderna de capacidad necesita contingencias: margen, opciones multi-proveedor y trabajo de eficiencia a nivel de carga.

Qué hacer: pasa de la planificación de una sola línea “N+1 es más rápido” a la planificación por escenarios: mejor caso, esperado, peor caso. Ata cada escenario a un plan de mitigación (optimizar, escalar, cambiar tipo de instancia o proveedor).

Compras dejó de ser “comprar lo siguiente” y se volvió una función de fiabilidad

Los equipos de compras antes pedían un número a ingeniería: “¿Cuántos servidores el próximo año?” Ahora la respuesta correcta suele ser un árbol: “Si obtenemos la CPU gen X en Q2, hacemos el plan A; si no, plan B con otro SKU; si la restricción es potencia, plan C con otra densidad.”

Eso no es indecisión. Es resiliencia. Tu cadena de suministro es parte de tu sistema ahora, te guste o no.

Ingeniería de rendimiento se volvió más honesta

Tick-tock permitió mucha pereza en postura de rendimiento. El declive forzó a los equipos a enfrentar cuellos de botella reales: complejidad algorítmica, contención de locks, localidad de memoria, amplificación de I/O y el hecho de que algunas cargas son intrínsecamente caras.

Eso duele. También libera. Cuando dejas de esperar una CPU mágica, comienzas a arreglar el problema real.

Las mitigaciones de seguridad y microcódigo se convirtieron en parte del rendimiento base

Otro cambio operativo: el rendimiento ya no es “hardware + software”, es “hardware + software + microcódigo + mitigaciones”. Tu suite de benchmarks debe incluir versiones de kernel realistas, microcódigo realista y tu configuración de producción real. Si no, comprarás una sorpresa cara.

Tres micro-historias corporativas desde el terreno

Micro-historia #1: El incidente causado por una suposición equivocada (“la próxima generación nos salvará”)

La compañía: un proveedor SaaS de tamaño medio con una carga de trabajo intermitente y una curva de crecimiento constante. La plataforma ejecutaba una capa de servicios Java, una capa de caché tipo Redis y una capa de metadatos respaldada por almacenamiento. Su plan de capacidad asumía una gran mejora de CPU que aterrizaría en Q3. No la necesitaban para la carga media—solo para los picos del percentil 99 que ocurrían durante trabajos por lotes de clientes.

La suposición equivocada era sutil: asumieron que podrían “resistir” los picos con la holgura existente hasta la renovación. Aplazaron dos tareas importantes: eliminar un lock global en el servicio de metadatos y reducir CPU gastada en serialización JSON.

La renovación se retrasó. No por una semana. Lo suficiente como para que la curva de crecimiento les alcanzara. Una noche de viernes, un cliente con muchos procesos por lotes ejecutó un nuevo trabajo, los picos llegaron, la saturación de CPU se convirtió en encolamiento, la latencia de cola explotó y las cachés empezaron a agitarse. La capa de metadatos entró en una espiral mortal: timeouts causaron reintentos; los reintentos amplificaron la carga; el lock global se calentó; la CPU fue al 100% y se quedó ahí.

Se recuperaron reduciendo carga y deshabilitando temporalmente los trabajos más pesados del cliente. La solución real tomó dos sprints: eliminar el lock y reemplazar la ruta de serialización por un formato binario más barato para llamadas internas. Después, el servicio funcionó bien en las CPUs antiguas. La renovación pasó a ser un bonito extra, no un soporte vital.

La lección: trata las hojas de ruta de los proveedores como pronósticos meteorológicos. Útiles, pero no cancelas la reparación del techo porque el pronóstico dice sol.

Micro-historia #2: La optimización que salió mal (“más núcleos lo arreglarán”)

La compañía: una plataforma interna de análisis con una gran flota de nodos de cálculo. Sus trabajos eran mixtos: algunos embarrassingly parallel, otros no. Subieron a un SKU con mayor conteo de núcleos en la misma generación de proceso, esperando ganancias lineales de throughput. También aumentaron los límites de CPU de los contenedores para “dejar respirar a los trabajos”.

El throughput mejoró en papel para un subconjunto de cargas. Luego otra clase de trabajos empezó a fallar en plazos. Las investigaciones mostraron mayor latencia de cola y menor rendimiento efectivo por núcleo. Las CPUs con más núcleos corrían a frecuencias turbo menores en carga sostenida, y el subsistema de memoria se volvió el cuello de botella. Más núcleos significaron más contención en ancho de banda de memoria y caché, y algunos trabajos se volvieron más lentos porque eran sensibles a la velocidad por hilo.

Peor aún, subir los límites de CPU de los contenedores aumentó los efectos de vecino ruidoso. Algunos trabajos agresivos consumieron el LLC compartido y el ancho de banda de memoria, dejando a otros con menos recursos. El scheduler hizo lo que pudo, pero la física no se impresionó. La gente culpó a las nuevas CPUs, luego a Kubernetes, luego unos a otros. Clásico.

Se estabilizaron clasificando las cargas: los trabajos sensibles por hilo se asignaron a un pool de nodos distinto con otro SKU y límites de CPU más estrictos; los trabajos hambrientos de ancho de banda ajustaron conteo de hilos; y añadieron monitorización de ancho de banda de memoria al control de admisión. La “actualización” aún ayudó en general, pero solo después de deshacer la simplista suposición “núcleos = velocidad”.

La lección: el conteo de núcleos no es una moneda universal. Tu carga paga en latencia, ancho de banda, localidad de caché y overhead del scheduler. Presupuesta en consecuencia.

Micro-historia #3: La práctica aburrida pero correcta que salvó el día (“mantén una canalización de calificación”)

La compañía: un servicio adyacente a pagos donde las interrupciones son profesionalmente embarazosas. Habían vivido suficientes transiciones de hardware como para desconfiar de grandes renovaciones. Su práctica era poco glamorosa: mantener un pequeño clúster de calificación que siempre ejecuta el siguiente hardware y combinación de kernel, continuamente, con reproducción de carga similar a producción.

Cuando la cadencia del proveedor empezó a tambalear, no entraron en pánico. Ya tenían un proceso de entrada: nuevas versiones de BIOS, nuevo microcódigo, nuevo kernel y nuevos SKUs de CPU iban a ese clúster con pruebas repetibles—histogramas de latencia, contadores perf, latencia de almacenamiento y comportamiento de potencia/temperatura.

En un ciclo, descubrieron que una actualización de BIOS cambió límites de potencia y comportamiento de turbo, causando un aumento medible en la latencia de cola bajo carga intermitente. Nada estaba “roto”, pero su margen de SLO se redujo. Como lo encontraron temprano, negociaron otra configuración de BIOS y ajustaron reglas de despliegue antes de que la renovación llegara a disponibilidad general.

Cuando el calendario de renovación se retrasó, simplemente siguieron comprando un SKU conocido y se mantuvieron dentro de las restricciones de potencia/enfriamiento. La canalización aburrida hizo que no apostaran la producción a la esperanza. Apostaron a los datos.

Broma #2: Su clúster de calificación era tan aburrido que nadie quería demostrarlo—hasta que previno un Sev-1, momento en el cual se convirtió en la piedra favorita de todos.

Guía rápida de diagnóstico: qué comprobar primero/segundo/tercero

Esta es la versión de on-call. No estás escribiendo una tesis; intentas detener la hemorragia e identificar el recurso limitante en minutos.

Primero: ¿es saturación de CPU o inanición de CPU?

• Comprueba uso de CPU vs cola de ejecución: alto uso de CPU con cola de ejecución alta sugiere verdadera saturación; uso bajo de CPU con alta latencia sugiere bloqueo (I/O, locks, throttling).
• Comprueba throttling: cuotas de cgroup de CPU, throttling térmico o límites de potencia pueden imitar “CPUs lentas”.

Segundo: ¿el cuello de botella es memoria, I/O o contención?

• Presión de memoria: busca reclaim, actividad de swap, fallos mayores. La CPU puede estar “ocupada” gestionando páginas.
• Espera de I/O y latencia de almacenamiento: el encolamiento en discos o almacenamiento en red aparece como hilos ejecutables esperando.
• Contención de locks: alto tiempo en sistema, muchos cambios de contexto o hotspots de mutex a nivel de aplicación pueden dominar.

Tercero: confirma con contadores y flame graphs

• Perf top / perf record: encuentra funciones calientes y confirma si estás bound por cómputo o atascado por memoria.
• Frecuencia de CPU y límites de potencia: verifica el comportamiento real de frecuencia bajo carga.

Cuarto: compara con una línea de base conocida

Si tienes una flota mixta, compara la misma carga en CPUs viejas vs nuevas, mismo kernel, mismo microcódigo. La deriva generacional es a menudo deriva de configuración disfrazada de silicio.

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

Estas son las tareas de “¿qué hago ahora mismo?”. Están escritas para servidores Linux en un entorno típico de centro de datos. Ejecuta como root cuando sea necesario.

Tarea 1: Identificar modelo de CPU y nivel de microcódigo

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Thread|Core|CPU\(s\)'
CPU(s):                          64
Thread(s) per core:              2
Core(s) per socket:              16
Socket(s):                       2
Model name:                      Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz

cr0x@server:~$ dmesg | grep -i microcode | tail -n 3
[    0.412345] microcode: microcode updated early to revision 0x2000065, date = 2023-07-11
[    0.412678] microcode: CPU0: patch_level=0x2000065
[    0.413012] microcode: CPU1: patch_level=0x2000065

Significado: Sabes exactamente qué silicio y microcódigo estás benchmarking. El microcódigo afecta mitigaciones y, a veces, el rendimiento.

Decisión: Si dos clusters difieren en microcódigo, deja de compararlos como si fueran equivalentes. Alinea el microcódigo antes de culpar a la generación de CPU.

Tarea 2: Comprobar comportamiento actual de frecuencia de CPU (turbo, señales de throttling)

cr0x@server:~$ cat /proc/cpuinfo | awk -F: '/cpu MHz/{sum+=$2; n++} END{printf "avg MHz: %.0f\n", sum/n}'
avg MHz: 1895

Significado: La media de MHz está por debajo de lo esperado para base/turbo bajo carga o debido a políticas de potencia.

Decisión: Si el rendimiento es “peor de lo esperado”, verifica la escalación de frecuencia y los límites de potencia antes de reescribir código.

Tarea 3: Verificar el governor de cpufreq (cuando aplique)

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

Significado: El sistema favorece la eficiencia energética; las cargas sensibles a latencia pueden sufrir.

Decisión: Para capas críticas de latencia, considera poner performance (después de validar margen de potencia/temperatura).

Tarea 4: Comprobar load average, cola de ejecución y steal de CPU

cr0x@server:~$ uptime
 10:41:12 up 47 days,  3:18,  2 users,  load average: 62.21, 58.03, 41.77

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.1.0 (server) 	01/10/2026 	_x86_64_	(64 CPU)

10:41:19 AM  CPU   %usr %nice  %sys %iowait  %irq %soft  %steal %idle
10:41:20 AM  all   71.2  0.0   8.7   0.3     0.0  0.8    0.0    19.0
10:41:21 AM  all   72.1  0.0   9.1   0.2     0.0  0.7    0.0    17.9
10:41:22 AM  all   70.4  0.0   8.9   0.2     0.0  0.8    0.0    19.7

Significado: Carga alta con %usr alto sugiere saturación de CPU; %iowait bajo sugiere que no está limitado por almacenamiento. No hay steal, por lo que no parece un problema de hypervisor con vecinos ruidosos.

Decisión: Si %usr es alto y la latencia sigue la carga, escala horizontalmente o reduce el coste de CPU por solicitud; no pierdas tiempo ajustando discos.

Tarea 5: Identificar los mayores consumidores de CPU (triage rápido)

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
23104 java            612.3 18.1
18422 envoy           155.7  1.2
 9921 node             88.4  3.8
 4137 postgres         62.1  6.4

Significado: Un proceso consume múltiples núcleos fuertemente; probablemente el cuello de botella está en la ruta de código o configuración de ese servicio.

Decisión: Enfoca el profiling en el mayor culpable; no ajustes parámetros aleatorios del kernel “por si acaso”.

Tarea 6: Detectar throttling de CPU por cgroup (contenedores)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.stat
usage_usec 178122938412
user_usec 162331112009
system_usec 15791826403
nr_periods 1831221
nr_throttled 421112
throttled_usec 11231398122

Significado: nr_throttled y throttled_usec son grandes: la carga está siendo limitada por la cuota de CPU.

Decisión: Si la latencia se correlaciona con el throttling, ajusta límites/requests de CPU o mueve a un pool sin cuotas estrictas.

Tarea 7: Comprobar presión de memoria y actividad de reclaim

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
28  1      0  84212  90124 812344    0    0    12    45 9021 22133 71 10 18  1  0
31  0      0  79044  90124 810102    0    0    14    22 9104 23110 72  9 19  0  0
34  2      0  61012  90124 804991    0    0    11    31 9442 24998 69 12 17  2  0
35  3      0  33200  90124 799812    0    0    19    55 9901 27120 65 14 18  3  0
38  5      0  12044  90124 795103    0    0    21    61 10312 30002 61 16 18  5  0

Significado: La cola de ejecución (r) es alta; la memoria libre se colapsa; hay algo de bloqueo (b) y aumentan los cambios de contexto. Te acercas a una presión de memoria que puede convertir la CPU en una máquina de paginación.

Decisión: Si los fallos mayores/reclaim aumentan, reduce la huella de memoria o añade RAM; no asumas que “CPUs más rápidas” arreglan la presión de memoria.

Tarea 8: Comprobar swap y fallos mayores explícitamente

cr0x@server:~$ sar -B 1 3
Linux 6.1.0 (server) 	01/10/2026 	_x86_64_	(64 CPU)

10:42:31 AM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
10:42:32 AM      0.00     62.00   9212.00     12.00  24120.00      0.00      0.00      0.00      0.00
10:42:33 AM      0.00     71.00   9440.00     15.00  25201.00      0.00      0.00      0.00      0.00
10:42:34 AM      0.00     58.00   9011.00     11.00  23210.00      0.00      0.00      0.00      0.00

Significado: Los fallos mayores no son triviales; si suben, verás picos de latencia y “desperdicio” de CPU.

Decisión: Trata los fallos mayores como amenaza al SLO; invierte en eficiencia de memoria o aisla al culpable.

Tarea 9: Confirmar latencia y encolamiento de almacenamiento

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

Device            r/s     w/s   rMB/s   wMB/s  rrqm/s  wrqm/s  %util  await  r_await  w_await
nvme0n1          12.0    48.0     1.2     9.8     0.0    22.0   94.1   18.4     4.1    22.0

Significado: El disco está casi saturado (%util alto) y la espera media está elevada; tu “cuello de botella de CPU” podría ser en realidad encolamiento de I/O.

Decisión: Si el almacenamiento está caliente, reduce escrituras sincrónicas, ajusta batching, añade dispositivos o mueve datos calientes a capas más rápidas—no compres más CPUs.

Tarea 10: Comprobar errores de red y descartes (fuente de latencia oculta)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    98341234123 81234123      0   10231       0    1123
    TX:  bytes packets errors dropped carrier collsns
    77123123123 70123123      0    8221       0       0

Significado: Paquetes descartados pueden traducirse en retransmisiones, latencia de cola y overhead “misterioso” de CPU en la pila de red.

Decisión: Si los descartes suben durante incidentes, inspecciona colas de NIC, ajustes del driver y congestión upstream. Las mejoras de CPU no arreglan la pérdida de paquetes.

Tarea 11: Comprobar presión del scheduler y cambios de contexto

cr0x@server:~$ pidstat -w 1 3
Linux 6.1.0 (server) 	01/10/2026 	_x86_64_	(64 CPU)

10:43:22 AM   UID       PID   cswch/s nvcswch/s  Command
10:43:23 AM     0     23104   12010.0   22100.0  java
10:43:23 AM     0     18422    3100.0    9020.0  envoy
10:43:23 AM     0      4137     820.0    1100.0  postgres

Significado: Altos context switches no voluntarios sugieren que hilos están siendo preemptados—a menudo por contención de CPU o de locks.

Decisión: Si nvcswch/s es enorme, investiga conteos de hilos, contención de locks y cuotas de cgroup antes de añadir nodos.

Tarea 12: Encontrar hotspots de aplicación con perf (rápido)

cr0x@server:~$ sudo perf top -p 23104
Samples: 1K of event 'cycles', 4000 Hz, Event count (approx.): 250000000
  18.22%  java    libjvm.so           [.] SpinPause
  12.10%  java    libpthread-2.36.so  [.] pthread_mutex_lock
   9.44%  java    libjvm.so           [.] Unsafe_Park
   7.51%  java    libc-2.36.so        [.] memcpy

Significado: Estás quemando ciclos en spinning y mutex locks, no en “trabajo útil”. Eso es contención.

Decisión: Arregla concurrencia (sharding de locks, reducir secciones críticas), ajusta pools de hilos o reduce estado compartido. Las nuevas CPUs no solucionan una fiesta de mutex.

Tarea 13: Comprobar layout NUMA y si estás thrashiendo entre sockets

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-15 32-47
node 0 size: 192000 MB
node 0 free: 41000 MB
node 1 cpus: 16-31 48-63
node 1 size: 192000 MB
node 1 free: 12000 MB

Significado: La memoria está desequilibrada; el nodo 1 está justo. Puede aumentar el acceso remoto a memoria, dañando la latencia.

Decisión: Si la latencia de cola se correlaciona con el desequilibrio NUMA, pincha procesos/allocators o redistribuye la carga entre sockets.

Tarea 14: Verificar límites de potencia y pistas de throttling térmico vía mensajes del kernel

cr0x@server:~$ dmesg | egrep -i 'thrott|powercap|therm' | tail -n 5
[183112.991201] powercap_intel_rapl: package-0 domain package locked by BIOS
[183114.102233] CPU0: Core temperature above threshold, cpu clock throttled
[183114.102241] CPU0: Package temperature/speed normal

Significado: Estás literalmente limitado por calor. Eso no es una “CPU mala”, es una restricción ambiental.

Decisión: Arregla la refrigeración, los ajustes de BIOS de potencia, curvas de ventilador o la colocación de cargas. Si no, comprarás CPUs más rápidas y las harás correr más lento.

Tarea 15: Comparar estado de mitigaciones del kernel (sensible al rendimiento)

cr0x@server:~$ grep . /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; IBRS_FW; STIBP: conditional

Significado: Las mitigaciones están habilitadas; pueden cambiar el rendimiento de cargas con muchas syscalls o cambios de contexto.

Decisión: No compares benchmarks entre flotas con distinto estado de mitigaciones; estandariza la política y mide el impacto.

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

1) “Las CPUs nuevas son más lentas”

Síntoma: Tras una renovación, el throughput está plano o peor; la latencia de cola empeora bajo carga.

Causa raíz: Límites de potencia/ajustes de BIOS reducen la frecuencia sostenida; mayor conteo de núcleos baja el turbo en carga sostenida; la carga es sensible por hilo.

Solución: Verifica frecuencias reales bajo carga de producción; ajusta perfiles de potencia de BIOS; divide cargas en pools por núcleo vs throughput; ajusta conteos de hilos.

2) “La CPU está al 60%, pero la latencia es terrible”

Síntoma: CPUs no saturadas, pero spikes de latencia p99.

Causa raíz: Throttling de cgroup, contención de locks, reclaim de memoria o encolamiento de I/O causan bloqueo en lugar de saturación pura de CPU.

Solución: Revisa cpu.stat de throttling, hotspots de perf, vmstat de reclaim y iostat await. Arregla el recurso bloqueante, no el tamaño de CPU.

3) “Esperamos la siguiente generación y fallamos el SLO”

Síntoma: Proyectos aplazados a la espera de un uplift de hardware; el acantilado de rendimiento llega cuando la renovación se retrasa.

Causa raíz: Dependencia de hoja de ruta usada como sustituto del trabajo de ingeniería; no hay contingencia.

Solución: Mantén un plan de peor caso: optimiza rutas críticas ahora, guarda una flota de calificación y presupuestiza margen.

4) “Benchmark dice 25% de mejora, producción dice 3%”

Síntoma: Resultados de laboratorio no coinciden con la realidad.

Causa raíz: Benchmarks ejecutados con distinto kernel/microcódigo, distintas mitigaciones, I/O poco realista o sin patrones de contención.

Solución: Construye pruebas de carga parecidas a producción incluyendo almacenamiento/red, límites realistas de contenedores, mismo kernel y microcódigo, y métricas de distribución de latencia.

5) “Más núcleos arreglaron throughput pero aumentaron jitter”

Síntoma: El rendimiento medio mejora; p99/p999 empeoran.

Causa raíz: Contención de vecinos ruidosos en caché/ancho de banda de memoria; overhead del scheduler; comportamiento del GC cambia con el conteo de núcleos.

Solución: Aísla cargas sensibles a latencia; aplica controles de CPU/ancho de banda de memoria donde sea posible; ajusta GC y pools de hilos para la nueva topología.

6) “La flota es idéntica, pero la mitad de nodos son raros”

Síntoma: Mismo SKU, distinto rendimiento, throttling intermitente.

Causa raíz: Deriva de BIOS, diferencias de firmware, diferencias de microcódigo, variación en refrigeración o mala población de DIMMs afectando canales de memoria.

Solución: Trata el firmware como configuración; aplica BIOS/firmware dorado; audita layout de DIMMs; monitoriza telemetría térmica; cuarentena a los outliers.

Listas de verificación / plan paso a paso

Paso a paso: cómo planificar una renovación cuando la cadencia es poco fiable

1. Inventario de la realidad. Registra modelo de CPU, microcódigo, kernel, BIOS, configuración de memoria, almacenamiento y firmware de NIC. Nada de “más o menos igual”.
2. Construye una taxonomía de cargas. Sensible por hilo, batch de throughput, ligado a ancho de banda de memoria, I/O-bound, mixto. Asigna responsables.
3. Define métricas de éxito. No “más rápido”. Usa latencias p50/p95/p99, coste por petición, vatios por petición, tasa de quema de presupuesto de errores y modos de fallo.
4. Establece un pool de calificación. Pequeño pero siempre activo. Ejecuta tráfico canario o reproducciones constantemente.
5. Estandariza microcódigo + mitigaciones para las pruebas. Mide con la política de producción; documenta diferencias.
6. Ejecuta A/B con envelopes de potencia iguales. Si un SKU está limitado por potencia en tus racks, eso importa más que la especificación pico.
7. Mide restricciones “aburridas”. Potencia de rack, refrigeración, oversubscription top-of-rack, profundidades de cola de almacenamiento y topología NUMA.
8. Ten un plan si se retrasa. Si la próxima generación no llega, ¿qué compras? ¿Qué trabajo de optimización aceleras? ¿Qué gestión de demanda aplicas?
9. Despliega con guardrails. Canario, luego 5%, luego 25%, luego el resto. Gatea por SLOs y regresiones, no por fechas del calendario.
10. Escribe el postmortem incluso si fue bien. Captura qué te sorprendió; ese es el registro de riesgos del próximo ciclo.

Lista de verificación: diagnosticar “esperábamos mejora y no la tuvimos”

• Confirma versión de kernel idéntica y parámetros de arranque.
• Confirma revisión de microcódigo y estado de mitigaciones.
• Comprueba perfil de energía del BIOS, ajustes de turbo y power caps.
• Verifica canales de memoria poblados correctamente; comprueba NUMA.
• Compara frecuencia sostenida bajo carga real, no en idle.
• Mide latencia de I/O y descartes de red durante pruebas de carga.
• Perfilado de hotspots: locks, syscalls, memcpy, GC, fallos de página.
• Comprueba cuotas de CPU de contenedores y contadores de throttling.
• Reejecuta con la misma mezcla de peticiones; confirma que no sea deriva de carga.

Lista de verificación: reducir dependencia de hoja de ruta (qué hacer este trimestre)

• Identifica los 3 servicios principales cuya planificación de capacidad asume “próxima generación”.
• Para cada uno, lista los 3 principales drivers de coste CPU y una alternativa arquitectónica.
• Implementa una optimización “victoria barata” (serialización, caching, batching, vectorización) y mide.
• Añade una barrera dura (límites de petición, backpressure, límites de cola) para prevenir tormentas de reintentos.
• Crea una alternativa de proveedor/instancia para cada capa, aunque nunca la uses.
• Haz que el cumplimiento de firmware/microcódigo sea parte de los checks de salud de la flota.

Preguntas frecuentes

1) ¿Fue tick-tock disciplina de ingeniería real o solo marketing?

Ambas cosas. Describía una alternancia genuina de riesgo que ayudó a la ejecución. También se convirtió en un atajo de marketing que hizo sonar el calendario más determinista de lo que era.

2) ¿Por qué dejó de funcionar tick-tock?

Porque las reducciones de proceso dejaron de ser “rutinarias”. La complejidad, los desafíos de rendimiento y la economía de nodos avanzados hicieron más difícil mantener el viejo ritmo anual.

3) ¿Una reducción de proceso siempre mejora el rendimiento?

No. A menudo mejora el potencial de eficiencia, pero el rendimiento real depende de objetivos de frecuencia, límites de potencia, margen térmico y decisiones de diseño. En data centers, la potencia y la refrigeración suelen decidir lo que realmente obtienes.

4) Si la cadencia de Intel es poco fiable, ¿deberíamos evitar Intel?

No practiques ideología. Haz gestión de riesgos. Califica al menos una ruta alternativa (otro proveedor, otro tipo de instancia o clase de hardware). Luego compra lo que satisfaga tus necesidades con el menor riesgo operativo.

5) ¿Cómo se relacionan las mitigaciones de seguridad con las fallas de tick-tock?

No “causan” los retrasos de proceso, pero cambiaron las expectativas operativas. Las comparaciones de rendimiento entre generaciones se volvieron más difíciles porque la línea base incluye microcódigo y mitigaciones del kernel que varían por plataforma y en el tiempo.

6) ¿Cuál es la conclusión operativa para equipos SRE?

Deja de planificar en torno a una única mejora prometida. Construye margen y opciones, mantén una canalización de calificación y invierte en eficiencia de carga para que las renovaciones de hardware sean aditivas, no existenciales.

7) ¿“Más núcleos” es una apuesta segura cuando las ganancias por núcleo disminuyen?

Sólo para cargas que escalan y que no estén limitadas por ancho de banda de memoria. Para capas sensibles a latencia, más núcleos pueden significar menor frecuencia por hilo y más contención. Mide antes de comprometerte.

8) ¿Cómo detectamos que estamos limitados por potencia o térmica en producción?

Busca MHz más bajos de lo esperado bajo carga, logs del kernel indicando throttling y rendimiento que mejora al reducir concurrencia. Si tu centro de datos está al límite de potencia/refrigeración, la hoja de especificaciones de la CPU es solo una sugerencia.

9) ¿Qué reemplazó conceptualmente a tick-tock para los planificadores?

Planificación por escenarios más calificación continua. En lugar de asumir una cadencia fija, asume variación y construye flexibilidad operativa: pools multi-SKU, aislamiento de cargas y proyectos de eficiencia.

10) ¿Cuál es el cambio de mayor palanca si estamos atascados en una generación antigua?

Perfila y elimina contención. Locks, reintentos y serialización ineficiente desperdician más CPU de lo que la gente quiere admitir, y también arruinan la latencia de cola.

Conclusión: próximos pasos prácticos

Tick-tock fue un regalo para operaciones porque hizo que el futuro pareciera programable. También enseñó a una generación de planificadores a externalizar su gestión de riesgos a la cadencia de un proveedor. Cuando la cadencia se rompió, no solo avergonzó las hojas de ruta—expuso suposiciones frágiles en modelos de capacidad, prácticas de calificación y cultura de ingeniería de rendimiento.

Haz lo siguiente:

• Construye (o resucita) un pool de calificación que pruebe continuamente el siguiente hardware previsto, kernel, BIOS y microcódigo juntos.
• Reescribe los planes de capacidad como escenarios, no como una única línea de previsión. Adjunta una mitigación a cada escenario.
• Adopta una regla de “prueba de base”: si no puedes explicar el rendimiento mediante frecuencia de CPU, throttling, mitigaciones y contadores de cuello de botella, no tienes permitido culpar a la generación de CPU.
• Invierte ahora en eficiencia de cargas—especialmente en contención y comportamiento de memoria—para no quedar rehén del próximo “tick” que puede o no llegar.

Tick-tock nunca fue una ley de la naturaleza. Fue una estrategia de ejecución. Diseña tus sistemas como si cada estrategia—la tuya y la de tu proveedor—eventualmente se encontrara con una fecha límite que no puede cumplir.