La decisión en una página: qué elegir y cuándo

Usa PostgreSQL cuando…

• Necesitas consultas ricas (contención, existencia, filtros anidados) y quieres que el optimizador tenga opciones. JSONB + GIN de PostgreSQL es la caja de herramientas madura.
• Quieres restricciones sobre datos semiestructurados: CHECK constraints, índices de expresión, columnas generadas e índices funcionales son ciudadanos de primera clase.
• Esperas que JSON permanezca más de un trimestre. PostgreSQL suele envejecer mejor cuando JSON se convierte en “esquema central”.
• Puedes operar vacuum con competencia. PostgreSQL te lo recompensará, pero solo si respetas el housekeeping de MVCC.

Usa MySQL cuando…

• Tu uso de JSON es principalmente almacenamiento de documentos + recuperación, no filtrado analítico intenso. Si las consultas son “buscar por id y devolver blob”, MySQL puede ir muy bien.
• Dependes de columnas generadas para proyectar rutas JSON calientes en escalares indexables. Este es el camino práctico de MySQL hacia la predictibilidad.
• Ya estás estandarizado operativamente en MySQL y JSON es una pequeña parte de la carga. Operaciones consistentes superan a la elegancia teórica.

Qué le diría a un equipo en producción

Si tus columnas JSON son un hack transitorio (ingesta rápida, normalizar después), elige la base de datos que tu equipo ya
opere bien. Pero si JSON es el contrato de interfaz (eventos, configuraciones, feature flags, atributos de usuario) y esperas consultar
dentro de él a escala, PostgreSQL suele ser la apuesta a largo plazo más segura.

MySQL puede rendir bien con JSON, pero a menudo exige que “declares las partes importantes” mediante columnas generadas e índices dirigidos.
Si no lo haces, acabarás explicándole a la dirección por qué tu esquema flexible se convirtió en latencia inflexible.

Una cita que debería estar en cada runbook de on-call: “La esperanza no es una estrategia.” — un máximo de operaciones ampliamente repetido (idea parafraseada).
Con JSON, esperar que la base de datos lo resuelva es la forma de comprarte un incidente de fin de semana.

Hechos e historia: cómo llegamos aquí

JSON en la base de datos parece moderno, pero la industria lleva décadas rondando esta idea: “almacena datos flexibles junto a los estructurados,
y consúltalos sin renunciar a la seguridad transaccional.” Los detalles difieren, y esos detalles son por qué estás leyendo esto en lugar de dormir.

8 hechos que vale la pena tener en la cabeza

1. PostgreSQL añadió JSON en 9.2 (2012), luego introdujo JSONB en 9.4 (2014) para almacenamiento binario y mejor indexación.
2. MySQL introdujo un tipo JSON nativo en 5.7 (2015); antes era TEXT con una oración y una regex.
3. JSONB normaliza el orden de claves y elimina claves duplicadas (la última clave gana). Eso es genial para indexación, sorprendente para “almacenar exactamente lo que envié”.
4. MySQL también almacena JSON en formato binario, y valida JSON al insertar, evitando algunos horrores de “blob inválido”.
5. Los índices GIN de PostgreSQL se construyeron originalmente para búsqueda de texto completo, luego se convirtieron en la herramienta para contención de JSONB.
6. Las columnas generadas de MySQL existen desde 5.7, y son la razón por la que muchos despliegues JSON en MySQL no colapsan.
7. MVCC en PostgreSQL significa que las actualizaciones crean nuevas versiones de fila; las actualizaciones grandes de JSON pueden amplificar el bloat a menos que vacuum esté al día.
8. Los formatos de replicación importan: binlog por fila de MySQL y logical decoding de PostgreSQL se comportan distinto bajo actualizaciones frecuentes de JSON y filas calientes.

Semántica JSON: qué almacenan realmente los motores

MySQL: JSON es un tipo, pero trátalo como documento a menos que proyectes campos

El tipo JSON de MySQL no es “TEXT con etiqueta.” Se valida, se almacena en una representación binaria y se manipula con funciones JSON.
Esa es la buena noticia. La noticia operacional es que rara vez obtendrás rendimiento sostenido a menos que hagas una de dos cosas:
(1) mantengas JSON mayormente de escritura-única/lectura-por-clave-primaria, o (2) extraigas las rutas consultadas con frecuencia en columnas generadas y las indexees.

MySQL te dejará escribir una consulta que parece selectiva pero no es indexable. El optimizador hará lo que pueda, luego escaneará.
A veces puedes rescatarla con índices funcionales (dependiendo de la versión) o columnas generadas, pero debes ser intencional.

PostgreSQL: JSONB es para consultar; JSON (texto) es para preservar la entrada exacta

PostgreSQL te ofrece dos filosofías diferentes:
json almacena el texto original (incluyendo espacios y orden), y
jsonb almacena un formato binario descompuesto optimizado para operadores e indexación.
Si quieres rendimiento, casi siempre querrás JSONB.

Los operadores de PostgreSQL son expresivos: contención (@>), existencia (?, ?|, ?&),
extracción por ruta (->, ->>, #>, #>>), y consultas JSON path.
Esa expresividad puede ser una trampa: la gente escribe filtros ingeniosos que parecen baratos y terminan con la CPU ahogada en descompresión o atascados en un índice que no coincide con el predicado.

Broma 1/2: JSON es como un cajón de sastre—todo cabe hasta que realmente necesitas encontrar las tijeras.

Indexación JSON: donde se gana o se pierde rendimiento

Indexación en MySQL: las columnas generadas son el movimiento adulto

En MySQL, indexar expresiones JSON arbitrarias ha mejorado con el tiempo, pero el patrón operacional más confiable sigue siendo:
define columnas generadas para las pocas rutas JSON que consultas todo el tiempo, cástralas a tipos escalares estables e índexalas.
Esto hace tres cosas:

• Le da al optimizador un índice B-tree normal que entiende.
• Evita extracciones JSON repetidas en tiempo de ejecución.
• Te obliga a admitir qué campos son realmente parte del “esquema real”.

La contrapartida: los cambios de esquema se vuelven más lentos y políticos, porque ahora el blob JSON tiene tentáculos en DDL y migraciones.
Eso no es un bug. Es el precio de fingir que los datos semiestructurados no tienen estructura (porque la tienen, una vez que dependes de ellos).

Cuando la indexación JSON de MySQL falla en la práctica

• Predicados excesivamente dinámicos (diferentes rutas JSON según la entrada del usuario) te empujan hacia escaneos.
• Comparar cadenas JSON con números provoca casts implícitos y rompe el uso de índices.
• Usar funciones en WHERE sin una expresión indexable hace que el optimizador se encoge de hombros y haga el trabajo de la forma lenta.

Indexación en PostgreSQL: GIN es potente, pero debes elegir la clase de operador

La historia de indexación JSONB de PostgreSQL es más fuerte, pero no es magia. Los índices GIN pueden acelerar contención y consultas de existencia,
pero tienen diferentes clases de operador:

• jsonb_ops: indexa más tipos de operaciones pero puede ser más grande.
• jsonb_path_ops: más compacto y rápido para contención, pero soporta menos operadores.

Si tu carga es “encuentra filas donde JSON contiene estos pares”, jsonb_path_ops suele ser la elección correcta.
Si necesitas existencia flexible y más soporte de operadores, jsonb_ops.
Elige mal y tendrás un índice que existe solo para hacer sufrir a VACUUM.

Índices de expresión: el puente práctico entre JSON y relacional

Si filtras frecuentemente por un campo extraído (por ejemplo, payload->>'customer_id'), un índice de expresión puede superar a un GIN amplio
en tamaño y predictibilidad. También es más fácil razonar sobre la selectividad.

Broma 2/2: Un índice GIN es como la cafeína—increíble cuando está dirigido, remordimiento cuando te excedes.

Patrones de consulta que separan “bien” de “arde todo”

Patrón 1: “Recuperar por id y devolver JSON” (poco riesgoso)

Tanto MySQL como PostgreSQL manejan esto bien. El coste dominante es I/O y tamaño de fila, no las funciones JSON.
Donde los equipos se lesionan es la lenta erosión: JSON crece, el tamaño de fila crece, la eficiencia de caché cae, y de repente “lecturas simples” se vuelven lecturas desde disco.

Patrón 2: “Filtrar por claves JSON con alta cardinalidad” (indexar o morir)

Si filtras por user_id, tenant_id, order_id dentro de JSON, en efecto estás filtrando por una clave relacional.
No finjas que es flexible. Promuévela: columna generada + índice en MySQL, índice de expresión en Postgres, o simplemente hazla una columna real.
Esto no es ideología. Es para evitar escaneos completos y planes de consulta inestables.

Patrón 3: “Analítica ad-hoc sobre JSON” (cuidado con la erosión lenta)

JSON atrae para analítica porque se autodescribe. En bases OLTP de producción, eso es una trampa.
La analítica ad-hoc tiende a:

• Usar funciones sobre muchas filas, causando consumo de CPU.
• Forzar escaneos secuenciales porque los predicados no coinciden con índices.
• Serializar tu carga en una tabla grande y un subsistema de disco caliente.

Si el negocio quiere analítica, o separa una réplica de reporting con guardrails estrictos, o transmite eventos a otro sitio.
“Solo ejecútalo en prod” es una decisión de presupuesto disfrazada de decisión de ingeniería.

Patrón 4: actualizaciones parciales a JSON (filas calientes, logs pesados)

Ambas bases pueden actualizar rutas dentro de JSON, pero las características de rendimiento difieren y el impacto operacional es parecido:
actualizaciones frecuentes a documentos JSON grandes significan más bytes escritos, más churn de índices, más trabajo de replicación y más invalidación de caché.

La regla práctica: si un campo JSON se actualiza con frecuencia y se lee con frecuencia, merece una columna real o una tabla separada.
JSON no es un pase libre sobre la normalización; es una factura diferida.

Actualizaciones, WAL/binlog y retraso de replicación

MySQL: volumen de binlog y realidades de replicación por fila

En MySQL, las actualizaciones grandes de JSON pueden producir eventos de binlog grandes—especialmente con replicación por fila. Si actualizas muchas filas o documentos grandes,
tus réplicas pagan el precio. El retraso de replicación rara vez es “un problema de la réplica”. Es un problema de amplificación de escritura de la aplicación.

También vigila el tamaño de las transacciones y la frecuencia de commits. Una carga que actualiza JSON en ráfagas puede crear picos desagradables: presión de fsync,
stalls en el flush de binlog y backlog del hilo SQL en la réplica.

PostgreSQL: presión de WAL + churn de MVCC

PostgreSQL escribe WAL por cambios, y MVCC significa que las actualizaciones crean nuevas versiones de fila. Actualiza frecuentemente un campo JSONB grande y obtendrás:
más WAL, más tuples muertas, más trabajo de vacuum y potencialmente más bloat de índices.

El retraso de replicación se manifiesta como backlog del WAL sender o demora de replay. La clave es distinguir:
la réplica no puede aplicar lo bastante rápido (limitada por CPU/I/O aplicando cambios) vs
el primario produce demasiado WAL (amplificación de escritura).

Guía operacional

• Mide bytes de WAL/binlog por segundo durante el pico. Es lo más cercano a la “verdad” sobre amplificación de escritura.
• Particiona o separa campos JSON calientes si las tasas de actualización son altas.
• En PostgreSQL, ajusta autovacuum para tablas con muchas actualizaciones de JSON, o la deuda de vacuum aparecerá como deuda de latencia.

Realidad de almacenamiento e I/O: bloat, churn de páginas y comportamiento de caché

Tamaño de fila y caché: tu impuesto invisible

Las columnas JSON agrandan las filas. Filas más grandes significan menos filas por página. Menos filas por página significa más lecturas de página para el mismo número de filas lógicas.
Esto se manifiesta como:

• Mayor churn en el buffer pool de MySQL (InnoDB).
• Más churn en shared_buffers de PostgreSQL.
• Más presión sobre la caché de páginas del SO.

La mayoría de las “regresiones de rendimiento misteriosas” tras añadir JSON son en realidad “duplicamos el tamaño de fila y nadie ajustó la memoria o patrones de acceso.”

Bloat en PostgreSQL: MVCC significa que le debes el collector vacuum

PostgreSQL no actualiza en sitio; crea nuevas versiones de fila. Si JSONB es grande y se actualiza frecuentemente, se acumulan tuples muertas y los índices churnean.
Autovacuum puede manejar mucho, pero necesita los umbrales correctos. Los ajustes por defecto están diseñados para ser seguros para principiantes, no óptimos para tu desastre.

MySQL: índices secundarios y presión de undo/redo

InnoDB de MySQL tiene su propia amplificación de escritura: redo logs, undo logs, doublewrite buffer, mantenimiento de índices secundarios.
Las actualizaciones grandes de JSON aumentan los bytes tocados y pueden empujarte a stalls de flush de logs. Lo verás como picos intermitentes de latencia,
“commits que de repente son lentos” y réplicas quedándose atrás.

Tareas prácticas: 14 comandos que puedes ejecutar hoy

Estos son los tipos de comandos que echo a correr durante un incidente o una revisión de rendimiento. Cada tarea incluye:
el comando, qué significa la salida y qué decisión tomar a continuación.
Los hostnames y rutas son deliberadamente aburridos; lo aburrido se repite.

Tarea 1 (MySQL): confirmar uso de JSON y presión de tamaño

cr0x@server:~$ mysql -e "SELECT table_schema, table_name, column_name, data_type FROM information_schema.columns WHERE data_type='json' ORDER BY table_schema, table_name;"
+--------------+------------+-------------+-----------+
| table_schema | table_name | column_name | data_type |
+--------------+------------+-------------+-----------+
| app          | events     | payload     | json      |
| app          | users      | attrs       | json      |
+--------------+------------+-------------+-----------+

Significado: ahora sabes qué tablas son candidatas a dolores relacionados con JSON.
Decisión: preselecciona las 1–3 tablas principales por recuento de filas y tasa de actualización. Ahí es donde importan la indexación y las decisiones de esquema.

Tarea 2 (MySQL): comprobar tamaños de tablas y huella de índices

cr0x@server:~$ mysql -e "SELECT table_name, table_rows, ROUND(data_length/1024/1024,1) AS data_mb, ROUND(index_length/1024/1024,1) AS index_mb FROM information_schema.tables WHERE table_schema='app' ORDER BY data_length DESC LIMIT 10;"
+------------+------------+---------+----------+
| table_name | table_rows | data_mb | index_mb |
+------------+------------+---------+----------+
| events     |    4821031 |  8120.4 |   2104.7 |
| users      |     820114 |  1190.8 |    412.2 |
+------------+------------+---------+----------+

Significado: las tablas con mucho JSON tienden a inflar data_mb.
Decisión: si data_mb crece más rápido que el crecimiento del negocio, necesitas limitar el tamaño del payload, comprimir aguas arriba o normalizar campos calientes.

Tarea 3 (MySQL): identificar predicados JSON lentos en el slow log

cr0x@server:~$ sudo pt-query-digest /var/log/mysql/mysql-slow.log --limit 5
#  1.2s user time, 40ms system time, 27.31M rss, 190.55M vsz
# Query 1: 0.68 QPS, 0.31x concurrency, ID 0xA1B2C3D4 at byte 91234
# Time range: 2025-12-28T00:00:00 to 2025-12-28T01:00:00
# Attribute    pct   total     min     max     avg     95%  stddev  median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Exec time     62   180s    120ms     12s    540ms     3s   900ms   300ms
# Rows examine  90  1200M      10   2.5M   360k   1.1M   500k   200k
# Query: SELECT ... WHERE JSON_EXTRACT(payload,'$.customer.id') = ?

Significado: rows examined es tu “impuesto por escaneo.” JSON_EXTRACT en WHERE sin índice es un sospechoso habitual.
Decisión: crea una columna generada para esa ruta (o un índice funcional si es apropiado) y reescribe la consulta para usarla.

Tarea 4 (MySQL): verificar si una consulta usa un índice

cr0x@server:~$ mysql -e "EXPLAIN SELECT id FROM app.events WHERE JSON_UNQUOTE(JSON_EXTRACT(payload,'$.customer.id'))='12345' LIMIT 10\G"
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: events
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 4821031
     filtered: 10.00
        Extra: Using where

Significado: type: ALL y sin key significa escaneo completo de tabla.
Decisión: no optimices buffers primero. Arregla el esquema/consulta: columna generada + índice, o rediseña.

Tarea 5 (MySQL): añadir una columna generada para una ruta JSON caliente

cr0x@server:~$ mysql -e "ALTER TABLE app.events ADD COLUMN customer_id VARCHAR(64) GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(payload,'$.customer.id'))) STORED, ADD INDEX idx_events_customer_id (customer_id);"
Query OK, 0 rows affected (2 min 41 sec)
Records: 0  Duplicates: 0  Warnings: 0

Significado: la columna generada STORED materializa el valor, el índice pasa a ser utilizable.
Decisión: reescribe las consultas de la aplicación para filtrar por customer_id en lugar de JSON_EXTRACT en WHERE. Luego vuelve a comprobar EXPLAIN.

Tarea 6 (MySQL): validar que el optimizador ahora usa el nuevo índice

cr0x@server:~$ mysql -e "EXPLAIN SELECT id FROM app.events WHERE customer_id='12345' LIMIT 10\G"
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: events
         type: ref
possible_keys: idx_events_customer_id
          key: idx_events_customer_id
      key_len: 258
          ref: const
         rows: 120
        Extra: Using index

Significado: pasaste de escanear millones a tocar ~120 filas.
Decisión: despliega el cambio y observa la latencia de escritura: mantener el nuevo índice aumenta el coste de escritura.

Tarea 7 (MySQL): comprobar retraso de replicación y presión de aplicación

cr0x@server:~$ mysql -e "SHOW REPLICA STATUS\G" | egrep "Seconds_Behind_Source|Replica_SQL_Running|Replica_IO_Running|Last_SQL_Error"
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 87
Last_SQL_Error:

Significado: hay lag aunque los threads estén activos. Usualmente la aplicación no puede aplicar tan rápido como escribe.
Decisión: mide la tasa de binlog y el tamaño de las transacciones; reduce el volumen de actualizaciones JSON o cambia el batching antes de culpar a la réplica.

Tarea 8 (PostgreSQL): listar columnas JSON/JSONB y sus tablas

cr0x@server:~$ psql -d appdb -c "SELECT table_schema, table_name, column_name, data_type FROM information_schema.columns WHERE data_type IN ('json','jsonb') ORDER BY 1,2,3;"
 table_schema | table_name | column_name | data_type
--------------+------------+-------------+-----------
 public       | events     | payload     | jsonb
 public       | users      | attrs       | jsonb
(2 rows)

Significado: alcance. Igual que MySQL: identifica las pocas tablas que más importan.
Decisión: céntrate primero en tablas con altas tasas de actualización y consultas cara al cliente.

Tarea 9 (PostgreSQL): encontrar las peores consultas JSON por tiempo total

cr0x@server:~$ psql -d appdb -c "SELECT calls, total_exec_time::bigint AS total_ms, mean_exec_time::numeric(10,2) AS mean_ms, rows, query FROM pg_stat_statements WHERE query ILIKE '%jsonb%' OR query ILIKE '%->%' OR query ILIKE '%@>%' ORDER BY total_exec_time DESC LIMIT 5;"
 calls | total_ms | mean_ms | rows |                   query
-------+----------+---------+------+-------------------------------------------
 18211 |   932144 |   51.20 |    0 | SELECT ... WHERE payload @> $1
  4102 |   512030 |  124.82 |    0 | SELECT ... WHERE (payload->>'customer')= $1
(2 rows)

Significado: tienes consultas calientes, no teorías.
Decisión: ejecuta EXPLAIN (ANALYZE, BUFFERS) en los principales culpables y construye el índice correcto para la forma del predicado.

Tarea 10 (PostgreSQL): inspeccionar un plan de consulta JSONB con buffers

cr0x@server:~$ psql -d appdb -c "EXPLAIN (ANALYZE, BUFFERS) SELECT id FROM events WHERE payload @> '{\"customer\":{\"id\":\"12345\"}}'::jsonb LIMIT 10;"
                                                          QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.42..8.44 rows=10 width=8) (actual time=0.088..0.146 rows=10 loops=1)
   Buffers: shared hit=42
   ->  Index Scan using idx_events_payload_gin on events  (cost=0.42..22134.77 rows=26235 width=8) (actual time=0.086..0.141 rows=10 loops=1)
         Index Cond: (payload @> '{"customer": {"id": "12345"}}'::jsonb)
         Buffers: shared hit=42
 Planning Time: 0.412 ms
 Execution Time: 0.182 ms
(7 rows)

Significado: index scan + mayormente buffer hits = saludable.
Decisión: conserva este índice si soporta rutas de producto centrales. Si es solo para consultas ad-hoc, no pagues el impuesto de escritura.

Tarea 11 (PostgreSQL): crear un GIN dirigido (elige la clase de operador)

cr0x@server:~$ psql -d appdb -c "CREATE INDEX CONCURRENTLY idx_events_payload_pathops ON events USING gin (payload jsonb_path_ops);"
CREATE INDEX

Significado: la construcción concurrente evita bloquear escrituras (a costa de tiempo y trabajo extra).
Decisión: usa jsonb_path_ops cuando la contención domine; de lo contrario considera jsonb_ops o índices de expresión.

Tarea 12 (PostgreSQL): construir un índice de expresión para una ruta caliente

cr0x@server:~$ psql -d appdb -c "CREATE INDEX CONCURRENTLY idx_events_customer_id_expr ON events ((payload->'customer'->>'id'));"
CREATE INDEX

Significado: esto hace que los predicados de igualdad sobre ese valor extraído sean previsibles y baratos.
Decisión: si esta ruta es estable y muy usada, considera promoverla a una columna real para reducir el procesamiento JSON por completo.

Tarea 13 (PostgreSQL): verificar señales de bloat y efectividad de autovacuum

cr0x@server:~$ psql -d appdb -c "SELECT relname, n_live_tup, n_dead_tup, last_autovacuum, last_vacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 5;"
 relname | n_live_tup | n_dead_tup |    last_autovacuum     |     last_vacuum
---------+------------+------------+------------------------+------------------------
 events  |    4809123 |     912044 | 2025-12-28 00:41:12+00 | 2025-12-22 03:11:02+00
 users   |     820104 |      12033 | 2025-12-28 00:38:01+00 | 2025-12-23 02:08:40+00
(2 rows)

Significado: las tuples muertas en events son altas; autovacuum está corriendo, pero puede estar subdimensionado para el churn de actualizaciones.
Decisión: ajusta umbrales de autovacuum por tabla, reduce la frecuencia de actualizaciones a JSONB grandes, o separa campos mutables.

Tarea 14 (Nivel sistema): identificar si estás limitado por I/O o CPU

cr0x@server:~$ iostat -x 1 5
Linux 6.1.0 (db01) 	12/29/2025 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.11    0.00    6.34   18.90    0.00   52.65

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1         320.0  18240.0     0.0   0.00    4.20    57.00   410.0  24576.0    9.80    59.95   6.10   92.0

Significado: %util alto y iowait significativo apuntan a saturación de almacenamiento. Las cargas JSON a menudo inflan I/O debido a filas más grandes y churn de índices.
Decisión: arregla patrones de consulta/índice primero; si sigue saturado, escala IOPS (mejores discos) o reduce la amplificación de escritura (cambios de esquema/diseño).

Guion de diagnóstico rápido

Cuando las consultas JSON se vuelven lentas, la gente pierde horas discutiendo “elección de base de datos” en lugar de encontrar el verdadero cuello de botella.
Este guion es el orden en que lo ejecutaría en un incidente—porque converge rápido.

Primero: demuestra si es un escaneo, una falta de índice o I/O bruto

• MySQL: ejecuta EXPLAIN en la consulta lenta. Si type: ALL, para y arregla el predicado/índice.
• PostgreSQL: ejecuta EXPLAIN (ANALYZE, BUFFERS). Si ves sequential scans en tablas grandes, necesitas un índice coincidente o reescribir la consulta.
• Sistema: comprueba iostat -x. Si el almacenamiento está al 100%, los escaneos y el bloat serán tus sospechosos principales.

Segundo: cuantifica la amplificación de escritura y presión de replicación

• MySQL: inspecciona el retraso de replicación y patrones de crecimiento del binlog; las actualizaciones grandes de JSON suelen correlacionarse con picos de lag.
• PostgreSQL: comprueba la generación de WAL y las tuples muertas; las actualizaciones intensas de JSON pueden convertir el vacuum en una crisis de fondo permanente.

Tercero: revisa la efectividad de caché y la erosión del tamaño de fila

• ¿Tu working set caliente sigue en memoria, o el crecimiento de JSON lo expulsó?
• ¿Añadiste un GIN amplio que duplicó el coste de escritura?
• ¿Alguien empezó a hacer filtros ad-hoc sobre claves JSON sin indexar?

Cuarto: arregla lo más pequeño que cambie la curva

• Promueve claves calientes a columnas reales (mejor) o a columnas generadas/índices de expresión (siguiente mejor).
• Añade el índice más adecuado para la forma del predicado, y valida con EXPLAIN.
• Si las actualizaciones son el problema, separa campos mutables del blob JSON.

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

Error 1: “La consulta parece selectiva pero es lenta”

Síntomas: la latencia crece con el tamaño de la tabla; EXPLAIN muestra escaneo completo; CPU se dispara en pico.

Causa raíz: extracción JSON en WHERE sin una expresión indexable (MySQL), o desacople entre operador e índice (PostgreSQL).

Solución: MySQL: columna generada STORED + índice B-tree; PostgreSQL: índice de expresión o clase de operador GIN correcta; reescribe el predicado para que coincida con el índice.

Error 2: “Añadimos un índice GIN y las escrituras se volvieron más lentas”

Síntomas: la latencia de insert/update aumenta; la tasa de WAL/binlog sube; el retraso de replicación empeora tras crear el índice.

Causa raíz: GIN amplio sobre JSONB grande con actualizaciones frecuentes; alto coste de mantenimiento de índice.

Solución: reemplaza por índices de expresión más estrechos; usa jsonb_path_ops si es solo contención; separa campos mutables; reconsidera si necesitas esa consulta en OLTP.

Error 3: “Postgres está lento con el tiempo; vacuum no da abasto”

Síntomas: tamaños de tabla e índice crecen; consultas lentas; autovacuum corre constantemente; tuples muertas altas.

Causa raíz: actualizaciones frecuentes a JSONB grandes crean muchas tuples muertas; umbrales de autovacuum no sintonizados para el churn de la tabla.

Solución: ajusta autovacuum por tabla; reduce frecuencia/tamaño de actualizaciones; mueve datos mutables a tabla separada; considera particionado para tablas tipo evento.

Error 4: “Lag de replicación en MySQL tras añadir características JSON”

Síntomas: Seconds_Behind_Source sube durante ráfagas; réplicas se recuperan lentamente; commits son espaciados.

Causa raíz: grandes eventos de binlog por fila derivados de actualizaciones JSON; transacciones sobredimensionadas; demasiados índices secundarios en proyecciones JSON.

Solución: reduce volumen de actualizaciones JSON; agrupa las operaciones de otra manera; limita las proyecciones indexadas a rutas realmente calientes; verifica ajustes de binlog/redo log y patrones de commit.

Error 5: “Almacenamos todo en JSON y ahora necesitamos restricciones”

Síntomas: valores inconsistentes en JSON; validaciones en la aplicación que se desbordan; consultas deben manejar claves faltantes y tipos erróneos.

Causa raíz: esquema externalizado al código de la aplicación; sin restricciones aplicadas; migraciones evitadas hasta demasiado tarde.

Solución: promueve campos clave a columnas; añade CHECK constraints (Postgres) o aplica columnas generadas + NOT NULL/tipos (MySQL); introduce payloads versionados.

Tres micro-historias corporativas desde las trincheras JSON

1) Incidente causado por una suposición errónea: “JSON es básicamente gratis de consultar”

Una compañía SaaS mediana lanzó un “feed de actividad” respaldado por una tabla de eventos. Cada evento tenía un payload JSON.
El equipo de producto quería filtrado: “mostrar solo eventos donde payload.actor.role = ‘admin’.” Fácil, pensaron.
El backend usaba MySQL, y la primera implementación usó JSON_EXTRACT en la cláusula WHERE.

En staging iba bien. En producción fue un desastre en cámara lenta: la tabla events era grande, y el filtro era popular.
La consulta parecía selectiva, pero hacía un escaneo completo, tocando millones de filas por petición en pico.
CPU al máximo, I/O saturado y todo el clúster desarrolló el síntoma de “todo es lento” que hace que los ejecutivos entren al canal de incidentes.

La suposición equivocada no fue “MySQL no puede hacer JSON.” Fue: “si el predicado es estrecho, la base de datos lo optimizará.”
Las bases optimizan lo que indexas, no lo que esperas. La extracción JSON sin expresión indexable no es estrecha; es matemática cara repetida en muchas filas.

La solución fue dolorosamente directa: añadir una columna generada STORED para actor_role, indexarla y cambiar la consulta.
El postmortem añadió una regla: cualquier clave JSON usada en un WHERE crítico debe proyectarse e indexarse, o moverse a una columna real.
El esquema flexible siguió existiendo, pero solo donde no estaba en la ruta crítica.

2) Optimización que salió mal: “Solo añade un GIN grande”

Otra empresa usaba PostgreSQL y tenía una única tabla masiva events con payloads JSONB.
Querían búsquedas ad-hoc más rápidas para soporte al cliente, así que alguien añadió un GIN amplio sobre todo el payload usando la clase de operador por defecto.
La velocidad de consulta mejoró al instante. Todos celebraron y siguieron adelante.

Dos semanas después, la latencia de escritura empezó a crecer. La actividad de autovacuum se volvió constante. Apareció retraso de replicación en picos.
El índice GIN era caro de mantener porque los payloads eran grandes y se actualizaban con campos de enriquecimiento.
El índice también creció rápido, aumentando la presión de checkpoints e I/O. La victoria de “búsqueda de soporte” se convirtió en “cada endpoint API es más lento”.

El problema no fue que GIN sea malo. Fue que indexaron todo, para una carga de consultas que en realidad no era central.
El índice convirtió la base de datos en un motor de búsqueda. PostgreSQL puede hacer eso, pero se paga en amplificación de escritura y bloat.

La solución eventual: eliminar el índice amplio, añadir dos índices de expresión para un puñado de claves usadas en filtros de soporte,
y sacar la búsqueda tipo texto completo fuera del camino OLTP. Soporte recuperó su flujo, pero producción dejó de pagar el impuesto en cada escritura.

3) Práctica aburrida pero correcta que salvó el día: “Haz del JSON un contrato, versiona y prueba”

Un equipo fintech almacenó metadata de verificación de clientes en JSONB en PostgreSQL. Incluía campos anidados, claves opcionales y bloques específicos por proveedor.
Sabían que estos datos evolucionarían, y también sabían que tendrían que consultar algunos campos de forma fiable para informes de cumplimiento.
Así que hicieron algo que parece poco sexy: añadieron una columna schema_version entero y escribieron migraciones explícitas para cambios en la forma del payload.

También promovieron unos campos críticos a columnas reales: customer_id, verification_status y vendor_name.
Todo lo demás vivía en JSONB. Encima de eso, tuvieron CHECK constraints que aseguraban que la columna status coincidiera con un conjunto conocido,
y tests de aplicación que validaban compatibilidad de esquema por versión.

Meses después, un proveedor cambió su formato de payload de forma sutil (un campo se movió más profundo).
Los equipos que almacenan JSON crudo sin contrato suelen descubrirlo cuando los informes fallan a las 2 a.m.
Este equipo lo descubrió en CI, porque un test de validación de esquema falló y la herramienta de migración obligó a una transformación explícita.

La práctica “aburrida” no fue un índice sofisticado. Fue tratar JSON como un contrato versionado, no como un cajón de sastre sin límites.
Producción se benefició: el rendimiento de consultas se mantuvo estable y la frecuencia de incidentes bajó—ese tipo de victoria que nunca recibe un correo de celebración.

Listas de verificación / plan paso a paso

Si estás iniciando una nueva feature con mucho JSON

1. Escribe los 5 principales patrones de consulta que esperas en los próximos seis meses (no solo la semana de lanzamiento).
2. Clasifica campos: inmutables vs mutables; frecuentemente filtrados vs raramente filtrados; alta cardinalidad vs baja cardinalidad.
3. Promueve los campos “frecuentemente filtrados y alta cardinalidad” a columnas reales (preferido) o a columnas generadas/índices de expresión.
4. Elige la estrategia de indexación específica por base de datos:
   • MySQL: columnas generadas STORED + índices B-tree; evita JSON_EXTRACT en cláusulas WHERE calientes.
   • PostgreSQL: índices de expresión para rutas calientes; GIN para contención/existencia; selecciona la clase de operador intencionalmente.
5. Fija presupuestos de tamaño de payload (límites suaves y duros). El crecimiento de JSON es silencioso hasta que no lo es.
6. Planifica la evolución: añade schema_version, documenta transformaciones y haz las migraciones rutinarias.

Si ya lo lanzaste y está lento

1. Encuentra las 3 consultas principales por tiempo total (slow log / pg_stat_statements).
2. Ejecuta EXPLAIN con la realidad (MySQL EXPLAIN, Postgres EXPLAIN ANALYZE BUFFERS). No adivines.
3. Añade el índice más pequeño que coincida con el predicado (índice de columna generada o índice de expresión) y verifica cambios de plan.
4. Mide el coste del lado escribiente tras indexar (latencia de commit, tasa WAL/binlog, retraso de replicación).
5. Si las actualizaciones son intensas, separa campos mutables del JSON y ponlos en otra tabla con clave correcta.
6. Pon guardrails a las consultas ad-hoc (timeouts, réplicas de lectura o una ruta de reporting dedicada).

Si estás decidiendo entre MySQL y PostgreSQL para JSON hoy

• Elige PostgreSQL si la consulta JSON es una característica de producto, no un detalle de implementación.
• Elige MySQL si JSON es mayormente almacenamiento y estás dispuesto a proyectar las claves calientes en columnas generadas indexadas.
• Elige la base de datos que tu equipo pueda operar en condiciones de incidente. Una característica teóricamente superior no despertará a tu on-call a las 3 a.m.

Preguntas frecuentes

1) ¿PostgreSQL siempre es mejor para JSON que MySQL?

No. PostgreSQL suele ser mejor para consultas complejas y indexación flexible. MySQL puede ser excelente cuando mantienes el uso de JSON simple
o proyectas rutas calientes en columnas generadas indexadas. “Siempre” es como empiezan los outages.

2) ¿Debería almacenar JSON como TEXT/VARCHAR en su lugar?

Usualmente no. Pierdes validación y muchos operadores JSON. Si realmente nunca consultas dentro del JSON y solo lo almacenas y recuperas,
TEXT puede servir—pero te cargas el riesgo de higiene de datos. Los tipos JSON nativos son más seguros para la corrección.

3) ¿Cuándo debe una clave JSON convertirse en una columna real?

Si se usa en joins, en WHERE calientes, para ordenación o se necesita para restricciones, debe ser columna. Si se actualiza frecuentemente,
probablemente sea columna o tabla separada. JSON es para variabilidad, no para identidad central.

4) ¿Los índices GIN resuelven el rendimiento de JSONB en PostgreSQL?

Resuelven algunos problemas. También pueden crear otros (coste de escritura, bloat, mantenimiento).
Usa GIN cuando tus predicados se alineen con contención/existencia y los datos indexados sean lo bastante estables para justificar el impuesto de escritura.

5) ¿Cuál es el equivalente en MySQL de un índice GIN en JSONB de Postgres?

No hay un equivalente directo. En MySQL típicamente creas columnas generadas que extraen valores escalares e indizas esos valores.
Es una filosofía diferente: decides qué importa desde el principio.

6) ¿Cómo evito “claves aleatorias por todas partes” en JSON?

Trata JSON como un contrato: versiona, valida y documenta las formas permitidas.
Aplica invariantes críticas con restricciones de base de datos (Postgres) o columnas generadas + NOT NULL/casts de tipo (MySQL).

7) ¿Por qué las actualizaciones parciales de JSON siguen sintiéndose caras?

Porque la “actualización parcial” a nivel SQL aún puede significar reescritura sustancial y churn de índices a nivel de almacenamiento,
además de volumen de WAL/binlog. Documentos grandes actualizados frecuentemente son caros, independientemente de lo bonito que se vea el SQL.

8) ¿Puedo usar JSON para datos multi-tenant y simplemente filtrar por tenant_id dentro del JSON?

Puedes, pero no deberías. El aislamiento por tenant pertenece a una columna real con índice.
Ponerlo en JSON facilita escanear accidentalmente entre tenants y complica hacer cumplir límites de rendimiento y restricciones.

9) ¿Cuál es el patrón híbrido más seguro?

Almacena campos centrales como columnas (ids, status, timestamps, claves foráneas), guarda campos opcionales/específicos de proveedor en JSON/JSONB,
e indexa solo el subconjunto pequeño de rutas JSON que realmente consultas. Todo lo demás permanece flexible sin impulsar el coste de las consultas centrales.

Conclusión: próximos pasos que no te avergüencen después

JSON en MySQL y PostgreSQL ya no es una novedad. Es una herramienta de producción—y como todas las herramientas de producción, recompensa la disciplina.
MySQL tiende a querer que proyectes estructura fuera del JSON e indexes explícitamente. PostgreSQL te da consultas e indexación más expresivas,
pero te cobrará en WAL, bloat y mantenimiento si indexas demasiado o actualizas campos JSONB grandes con demasiada frecuencia.

Pasos prácticos siguientes:

1. Identifica las 3 consultas JSON principales por tiempo total y ejecuta EXPLAIN con estadísticas reales de ejecución.
2. Promueve las 3 claves JSON principales usadas para filtrado/joining a columnas o columnas generadas/índices de expresión y indexalas.
3. Mide la amplificación de escritura (tasa WAL/binlog) antes y después de indexar; vigila el retraso de replicación.
4. Establece un presupuesto de tamaño de payload e implémentalo en la ingestión.
5. Versiona tus payloads JSON. El tú del futuro, de lo contrario, pasará un fin de semana descifrando “por qué a veces existe esta clave”.

Elige la base de datos que coincida con las fortalezas operativas de tu equipo, y luego diseña el uso de JSON como si esperases que se vuelva permanente—porque normalmente lo hace.

Qué significa realmente “copia lenta” (y qué no es)

“La copia en Windows es lenta” no es un problema único. Es un síntoma visible por el usuario de una canalización que incluye: comportamiento del cliente Windows, semántica del protocolo SMB, detalles de implementación de Samba, grupos de transacciones y rutas de escritura de ZFS, y latencia del medio físico. Tu tarea es encontrar la etapa que convierte ancho de banda en espera.

Los tres patrones de copia que debes separar

• Copias grandes y secuenciales (p. ej., ISO, VHDX): deberían correr cerca de la velocidad del enlace hasta que el servidor no pueda comprometer escrituras lo suficientemente rápido.
• Muchos archivos pequeños (p. ej., árboles de código): dominados por metadata (create, setattr, close, rename), no por el throughput.
• Cargas mixtas (carpetas personales + VMs + escáneres): “lento” suele ser bloqueo por cabeza de línea: un patrón malo arruina la cola para todos.

Lo que normalmente no es

Rara vez es “SMB es lento”. SMB3 puede ser muy rápido. Rara vez es “ZFS es lento”. ZFS puede saturar redes serias. Suele ser picos de latencia por escrituras síncronas, I/O aleatorio pequeño, amplificación de metadata o alineación de caché deficiente, visibles por un cliente que reporta velocidad en ráfagas optimistas.

Un cambio de encuadre más: Windows Explorer no es una herramienta de benchmark; es un visualizador de ansiedad. Ese gráfico es más anillo de humor que osciloscopio.

Hechos interesantes y contexto histórico (para entender el comportamiento)

1. SMB1 vs SMB2/3 lo cambió todo. SMB2 (era Vista/2008) redujo la verbosidad, aumentó lecturas/escrituras y añadió pipelining. Muchas historias de “SMB es lento” en realidad son “estás atascado en SMB1”.
2. Samba empezó como un proyecto reimplementado. Creció desde “hacer que UNIX hable con Windows” hasta un servidor SMB de nivel empresarial. Algunas configuraciones por defecto son conservadoras porque Samba debe sobrevivir clientes raros.
3. Las escrituras de ZFS se agrupan. ZFS compromete datos en grupos de transacciones (TXGs). Eso hace que el throughput sea excelente, pero también crea un comportamiento de “pulso” visible si la fase de commit se atrasa.
4. Las escrituras síncronas son una promesa, no una sensación. Cuando un cliente SMB solicita durabilidad, ZFS debe comprometer de forma segura. Si tu pool no puede hacer fsync de baja latencia, obtendrás el clásico gráfico “rápido y luego cero”.
5. Los manejadores durables y los leases de SMB cambiaron el comportamiento de close/open. Windows moderno cachea agresivamente. Eso es bueno, hasta que una aplicación fuerza semánticas de durabilidad y convierte el caching en dolor síncrono.
6. Recordsize importa más para compartidos que la gente admite. El recordsize de ZFS modela la amplificación de I/O. Un recordsize incorrecto no solo desperdicia espacio: fuerza IOPS extra bajo accesos aleatorios pequeños.
7. La compresión suele ayudar en SMB, incluso con CPUs rápidas. Muchos archivos de oficina se comprimen bien, reduciendo carga de disco y red. La ganancia suele ser en latencia, no en ancho de banda puro.
8. El signing de SMB se volvió más común por seguridad. Activar signing puede costar CPU. La configuración “segura” a veces se convierte en “seguramente lenta” cuando el servidor tiene CPU débil o está limitado por un solo hilo.

Guía rápida de diagnóstico

Este es el orden que encuentra el cuello de botella rápido, sin caer en la trampa de “afinar todo”.

Primero: clasifica la carga

• ¿Un archivo grande? ¿Muchos archivos pequeños? ¿Escrituras de aplicación con requisitos de durabilidad?
• ¿La velocidad cae a intervalos fijos (cada pocos segundos)? Eso huele a latencia de commit de TXG.
• ¿Ocurre solo en ciertos shares? Eso huele a propiedades del dataset o a opciones del share SMB.

Segundo: decide si es red, CPU o latencia de almacenamiento

• Red: errores de interfaz, retransmisiones, MTU incorrecto, hashing LACP malo, clientes Wi‑Fi fingiendo ser servidores.
• CPU: un núcleo saturado en smbd, sobrecarga por signing/encryption, interrupciones, saturación de softirq.
• Latencia de almacenamiento: alto await en vdevs, camino sync de ZFS bloqueado, SLOG ausente/lento, pool casi lleno o fragmentado.

Tercero: valida comportamiento sync (este suele ser el villano)

• Revisa la propiedad sync del dataset y las configuraciones de Samba que fuerzan sync (p. ej., strict sync).
• Mide la latencia de fsync desde el host SMB, no desde tu portátil.
• Si necesitas semánticas sync, asegúrate de un SLOG apropiado (protegido contra pérdida de energía) o acepta los límites de rendimiento de tus vdevs principales.

Cuarto: aisla el caso de “muchos archivos pequeños”

• La metadata es la carga. Revisa atime, comportamiento de xattr y rendimiento de bloques pequeños.
• Verifica que el layout del pool coincida con las expectativas de IOPS de metadata (tradeoffs espejos vs RAIDZ).

Quinto: ajusta solo lo que las mediciones implican

Si no puedes mostrar un antes/después en latencia de I/O, utilización de CPU o retransmisiones, no estás afinando: estás adornando.

Deja de adivinar: mide a dónde va el tiempo

Las copias SMB son una negociación entre un cliente que hace buffering y un servidor que compromete. Explorer reporta “velocidad” basado en qué tan rápido los datos son aceptados en buffers, no en qué tan rápido son escritos de forma duradera. Mientras tanto, ZFS puede aceptar datos rápidamente en ARC y buffers sucios, luego pausar mientras compromete TXGs. Esa pausa es donde el gráfico llega a cero.

Tu plan de medición debe responder tres preguntas:

1. ¿El cliente está esperando al servidor (latencia), o no está enviando (throttling del cliente)?
2. ¿El servidor espera a vaciados de disco (ruta sync) o a la CPU (signing/encryption) o a la red?
3. ¿ZFS amplifica la carga (mismatch de recordsize, fragmentación, presión de metadata)?

Ingeniería de confiabilidad tiene una regla simple aplicable aquí: mide el sistema que tienes, no el sistema que quisieras tener.

Idea parafraseada (Gene Kim): “Mejorar el flujo significa encontrar y eliminar la restricción.” Ese es todo el juego.

Realidades de ZFS que afectan a SMB

TXGs y el patrón “rápido y luego cero”

ZFS acumula datos sucios en memoria y periódicamente los compromete a disco como un grupo de transacción. Si la fase de commit toma demasiado tiempo, el sistema restringe a los escritores. Desde la vista del cliente: ráfaga rápida, luego stall. Repetir. Eso no es “jitter de red”. Es la durabilidad del almacenamiento poniéndose al día.

Escrituras síncronas: el impuesto de durabilidad

Cuando la carga emite escrituras síncronas (o cuando el servidor las trata así), ZFS debe asegurar que los datos estén en almacenamiento estable antes de reconocerlos. En pools sin un dispositivo de intent log rápido, las escrituras síncronas impactan tus vdevs principales. Si éstos son RAIDZ con HDDs, puedes predecir el resultado: dolor con marca temporal.

Recordsize, ashift y amplificación de I/O

El recordsize de ZFS controla el tamaño máximo de bloque para datos de archivo. Los compartidos SMB suelen almacenar archivos de tamaños mixtos; un recordsize demasiado grande no siempre dañará lecturas secuenciales, pero puede perjudicar escrituras aleatorias y sobreescrituras parciales. Uno demasiado pequeño puede aumentar la sobrecarga de metadata y reducir la eficiencia de compresión.

La metadata no es “gratis”

Las copias de archivos pequeños estresan la metadata: entradas de directorio, ACLs, xattrs, marcas de tiempo. ZFS puede manejar esto bien, pero solo si el layout del pool y la caché son sensatos. Si construiste un RAIDZ ancho para capacidad y luego lo usaste como un share SMB intensivo en metadata, básicamente compraste un autobús y lo inscribiste en una carrera de motocicletas.

Llenado del pool y fragmentación

A medida que los pools se llenan, la asignación se vuelve más difícil, la fragmentación sube y la latencia aumenta. Los usuarios SMB experimentan esto como “estaba bien el mes pasado”. ZFS no olvida repentinamente cómo escribir; se queda sin lugares fáciles para poner bloques.

Realidades de SMB que afectan a ZFS

Semántica de copia en Windows: buffering, close y durabilidad

Windows puede hacer buffering de escrituras y solo forzar durabilidad al cerrar el archivo, dependiendo de flags de aplicación y configuración del servidor. Algunas apps (y algunas herramientas de seguridad) solicitan write-through. Eso convierte tu carga de “mayormente async” a “intensamente sync” al instante.

Signing y encriptación: la seguridad tiene coste en CPU

El signing de SMB suele ser exigido por políticas. La encriptación puede estar habilitada para ciertos shares. Ambos consumen CPU. Si tu servidor SMB tiene una CPU modesta con NIC rápida, puedes alcanzar un techo donde la red está inactiva y un núcleo está sudando por la criptografía.

SMB3 Multichannel: genial cuando funciona, irrelevante cuando no

Multichannel puede usar múltiples NICs y colas RSS. Cuando está mal configurado, obtienes exactamente un flujo TCP atascado en una cola. Entonces alguien dice “pero tenemos doble 10GbE” como si el servidor estuviera obligado a ocuparse.

Opportunistic locks, leases y antivirus

El caching del cliente (oplocks/leases) reduce la verbosidad. Pero los escáneres de seguridad de endpoints adoran abrir archivos, forzar actualizaciones de atributos y, en general, romper el comportamiento de caching. Esto puede convertir una copia de “muchos archivos pequeños” en un festival de llamadas al sistema.

Broma #1: El troubleshooting de SMB es como la política de oficina: todos insisten en que son el cuello de botella y, de alguna manera, todos tienen razón.

Tareas prácticas: comandos, salidas, decisiones

A continuación hay tareas reales que puedes ejecutar en el servidor SMB/ZFS. Cada una incluye qué significa la salida y qué decisión debes tomar después. Están sesgadas hacia Linux + Samba + OpenZFS, porque ahí viven la mayoría de los tickets “la copia en Windows es lenta”.

Tarea 1: Confirma la salud del pool (porque el rendimiento suele ser síntoma de un disco moribundo)

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 04:12:19 with 0 errors on Tue Dec 10 03:20:01 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_A   ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_B   ONLINE       0     0     0

errors: No known data errors

Significado: “ONLINE” y scrub limpio significa que no estás luchando contra reintentos silenciosos o carga de resilver. Si ves DEGRADED, resilvering o errores de checksum, detén el tuning y arregla el hardware primero.

Decisión: Si algún vdev muestra errores o actividad de resilver, programa remediación y vuelve a probar el rendimiento después de la estabilización.

Tarea 2: Revisa el llenado del pool (los pools casi llenos se vuelven lentos de forma predecible)

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank   38.2T 2.1T   96K    /tank

Significado: ~95% usado (38.2T usados, 2.1T disponibles) es zona de peligro para muchas cargas. La asignación se vuelve restringida; la fragmentación sube.

Decisión: Si estás por encima de ~80–85% usado y el rendimiento importa, planifica recuperar/expandir espacio. Ningún ajuste de Samba vencerá a la física.

Tarea 3: Identifica qué dataset respalda el share SMB y muestra sus propiedades clave

cr0x@server:~$ sudo zfs get -H -o property,value recordsize,compression,atime,sync,xattr,acltype,primarycache,logbias tank/shares/engineering
recordsize	1M
compression	lz4
atime	on
sync	standard
xattr	sa
acltype	posixacl
primarycache	all
logbias	latency

Significado: Tienes recordsize 1M (bueno para archivos grandes secuenciales, riesgoso para sobreescrituras parciales), atime activado (escrituras de metadata extra), sync standard (sync respetado), xattr en SA (suele ser bueno), logbias latency (prefiere SLOG si está presente).

Decisión: Si el share es de “muchos archivos pequeños”, considera recordsize=128K y atime=off. Si son imágenes de VM, trátalo diferente (y probablemente no vía SMB).

Tarea 4: Mide latencia de I/O del pool durante una copia (la verdad está en iostat)

cr0x@server:~$ sudo zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        38.2T  2.1T     12   2400   3.1M   210M
  mirror-0                  38.2T  2.1T     12   2400   3.1M   210M
    ata-SAMSUNG_SSD_1TB_A      -      -      6   1250   1.6M   108M
    ata-SAMSUNG_SSD_1TB_B      -      -      6   1150   1.5M   102M
--------------------------  -----  -----  -----  -----  -----  -----

Significado: Operaciones de escritura altas (2400/s) con ancho de banda moderado sugiere escrituras pequeñas o comportamiento intensivo en sync. Si el ancho de banda es bajo pero las ops son altas, estás limitado por IOPS o por flushes.

Decisión: Si las escrituras son pequeñas y frecuentes, investiga semánticas sync, carga de metadata y mismatch de recordsize. Si las ops son bajas y el ancho de banda es bajo, sospecha red o throttling SMB.

Tarea 5: Observa latencia por vdev con iostat (await es la alarma)

cr0x@server:~$ sudo iostat -x 1 3
Linux 6.6.15 (server) 	12/25/2025 	_x86_64_	(16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1           2.0   950.0    64.0 118000.0   248.0     3.20    3.4     1.2      3.4    0.6   58.0
nvme1n1           1.0   910.0    32.0 112000.0   246.0     3.05    3.3     1.1      3.3    0.6   55.0

Significado: ~3.3ms de await en escritura está bien para NVMe. Si ves decenas/centenas de ms durante copias, el almacenamiento está limitando tu throughput.

Decisión: Await alto + CPU baja + red limpia = problema en la ruta de almacenamiento (escrituras sync, pool lleno, vdevs lentos o problemas con SLOG).

Tarea 6: Comprueba si tienes un SLOG (y si está haciendo algo)

cr0x@server:~$ sudo zpool status tank | sed -n '1,120p'
  pool: tank
 state: ONLINE
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_A    ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_B    ONLINE       0     0     0
        logs
          nvme-SLOG_INTEL_OPTANE     ONLINE       0     0     0

Significado: Hay un dispositivo de log separado. Bien. Pero la existencia no es rendimiento; debe ser rápido y protegido contra pérdida de energía.

Decisión: Si existen cargas sync y no hay SLOG, decide si necesitas semánticas sync. Si las necesitas, añade un SLOG adecuado. Si no, no lo falsifiques con sync=disabled a menos que estés cómodo perdiendo datos reconocidos en un corte de energía.

Tarea 7: Observa throttling de TXG y comportamiento de datos sucios

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c  avail
12:10:01   320    12      4     1    0    11    3     0    0   84.2G  96.0G  21.4G
12:10:02   410    16      3     2    0    14    3     0    0   84.2G  96.0G  21.4G
12:10:03   390    10      2     1    0     9    2     0    0   84.2G  96.0G  21.4G

Significado: ARC no está fallando gravemente; el caching no es tu restricción actual. Si ARC es pequeño respecto a la memoria, o los misses se disparan, podrías estar limitado por memoria o mal configurado.

Decisión: Si los misses de ARC son altos durante lecturas, ajusta tamaño de memoria/ARC o el working set (o acepta que la carga no cachea bien).

Tarea 8: Confirma versión de Samba y si se negoció SMB3

cr0x@server:~$ smbd -V
Version 4.19.5-Debian

cr0x@server:~$ sudo smbstatus -b | sed -n '1,60p'
Samba version 4.19.5-Debian
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
-------------------------------------------------------------------------------------------------------------------------
23144   user1        domain users  10.10.20.55 (ipv4:10.10.20.55:53122)     SMB3_11           -                    partial

Significado: Se negoció SMB3_11, bien. El signing está “partial” (depende de configuración y cliente). Si ves SMB1, tienes problemas mayores que tuning.

Decisión: Si aparece SMB1, desactívalo y arregla la compatibilidad del cliente intencionalmente. No mantengas SMB1 “por ese escáner legado”. Reemplaza el escáner o aíslelo.

Tarea 9: Revisa la configuración del share Samba en busca de killers de sync (strict sync, sync always)

cr0x@server:~$ sudo testparm -sv | sed -n '/^\[engineering\]/,/^\[/{p}'
[engineering]
	path = /tank/shares/engineering
	read only = No
	vfs objects = acl_xattr
	strict sync = Yes
	sync always = No

Significado: strict sync = Yes fuerza a Samba a vaciar más operaciones. Esta es una clásica configuración “la activamos por seguridad” que puede hundir el throughput.

Decisión: Si no tienes una necesidad de cumplimiento para semánticas estrictas, pon strict sync = No y valida la corrección de las aplicaciones. Si la necesitas, invierte en SLOG y almacenamiento de baja latencia.

Tarea 10: Verifica si signing/encryption están activados y si la CPU es el limitante

cr0x@server:~$ sudo smbstatus -b | awk 'NR==1 || NR==2 || $0 ~ /SMB3/'
Samba version 4.19.5-Debian
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
23144   user1        domain users  10.10.20.55 (ipv4:10.10.20.55:53122)     SMB3_11           AES-128-GCM          mandatory

cr0x@server:~$ top -b -n 1 | sed -n '1,20p'
top - 12:12:41 up 34 days,  3:01,  2 users,  load average: 9.12, 8.40, 7.95
Tasks: 291 total,   2 running, 289 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.1 us,  2.0 sy,  0.0 ni, 78.0 id,  0.0 wa,  0.0 hi,  7.9 si,  0.0 st
MiB Mem :  256000.0 total,  21000.0 free,  95000.0 used, 140000.0 buff/cache

Significado: La encriptación está activada. La CPU está mayormente inactiva aquí, por lo que la encriptación probablemente no es el cuello de botella en este momento. Si ves un núcleo pegado y softirq alto, vuelve a revisar.

Decisión: Si encryption/signing es obligatorio y la CPU está caliente, actualiza CPU, usa sistemas con AES-NI, asegúrate de RSS y multiqueue, o limita la encriptación a shares sensibles.

Tarea 11: Verifica enlace NIC, duplex y contadores de errores (chequeos baratos, consecuencias caras)

cr0x@server:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 9c:dc:71:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    1223344556677 1023344556      0       0       0  120034
    TX:  bytes packets errors dropped carrier collsns
    1334455667788 1124455667      0       0       0       0

cr0x@server:~$ ethtool bond0 | sed -n '1,25p'
Settings for bond0:
	Supported ports: [ ]
	Supported link modes:   Not reported
	Speed: 20000Mb/s
	Duplex: Full
	Auto-negotiation: off

Significado: Sin errores, full duplex, velocidad esperada. Si ves errores o drops, arregla la red antes de tocar ZFS.

Decisión: Si existen errores: revisa cableado, puertos del switch, consistencia de MTU y opciones de offload. Afinar sobre pérdida de paquetes es teatro de rendimiento.

Tarea 12: Revisa retransmisiones TCP y presión de sockets (SMB sobre una red enferma es mentira)

cr0x@server:~$ ss -s
Total: 884
TCP:   211 (estab 104, closed 72, orphaned 0, timewait 72)

Transport Total     IP        IPv6
RAW	  0         0         0
UDP	  11        8         3
TCP	  139       113       26
INET	  150       121       29
FRAG	  0         0         0

cr0x@server:~$ netstat -s | sed -n '1,80p'
Tcp:
    154239 active connection openings
    149802 passive connection openings
    1124 failed connection attempts
    1821 connection resets received
    0 connections established
    224159 segments received
    231008 segments sent out
    214 segments retransmitted

Significado: Existen retransmisiones pero no son locas. Si las retransmisiones saltan durante copias, verás stalls no relacionados con almacenamiento. SMB es sensible a picos de latencia.

Decisión: Retransmisiones altas: inspecciona buffers del switch, mismatch de MTU, driver/firmware de NIC o un path de firewall sobrecargado.

Tarea 13: Identifica si la carga es sync-heavy (prueba de fsync del servidor)

cr0x@server:~$ sync; sudo bash -c 'time dd if=/dev/zero of=/tank/shares/engineering/.fsync-test bs=1M count=256 conv=fdatasync status=none'
real	0m1.92s
user	0m0.00s
sys	0m0.28s

cr0x@server:~$ sudo rm -f /tank/shares/engineering/.fsync-test

Significado: Esto mide “escribir y luego forzar durabilidad”. Si esto es lento (p. ej., 10–60s), tu pool no puede comprometer escrituras sync lo suficientemente rápido para cargas SMB que las requieran.

Decisión: fsync lento: añade/valida SLOG, reduce flushes forzados en Samba si es aceptable, o rediseña almacenamiento para escrituras de baja latencia.

Tarea 14: Confirma que el dataset no está forzando sync accidentalmente (o lo contrario)

cr0x@server:~$ sudo zfs get -H -o name,property,value sync tank/shares/engineering tank/shares/finance
tank/shares/engineering	sync	standard
tank/shares/finance	sync	always

Significado: El share finance está forzado a sync=always. Eso puede ser intencional (apps que necesitan durabilidad) o una mala configuración que lo hace lento.

Decisión: Si sync=always existe, confirma con los dueños de la app por qué. Si nadie lo justifica, vuelve a standard y prueba.

Tarea 15: Revisa compresión y ratio real (porque “activamos compresión” no es igual a “está funcionando”)

cr0x@server:~$ zfs get -H -o name,property,value compression,compressratio tank/shares/engineering
tank/shares/engineering	compression	lz4
tank/shares/engineering	compressratio	1.62x

Significado: 1.62x significa que estás ahorrando I/O y espacio. Si el ratio está ~1.00x, la compresión no ayuda mucho pero normalmente LZ4 no perjudica.

Decisión: Mantén LZ4 casi siempre. Solo desactívalo si mides saturación de CPU y datos casi incomprimibles.

Tarea 16: Busca fragmentación patológica (especialmente si el pool es antiguo y casi lleno)

cr0x@server:~$ sudo zdb -bbbs tank | sed -n '1,40p'
Block Size Histogram:
 512: 0
 1K : 0
 2K : 1048576
 4K : 2097152
 8K : 1048576
 16K: 524288
 32K: 262144
 64K: 131072
 128K: 65536
 256K: 32768
 512K: 16384
 1M : 8192

Significado: Esto es una vista aproximada; en la práctica correlacionarás fragmentación con comportamiento de asignación y latencia. Una alta diversidad de bloques pequeños en un dataset pensado para escrituras grandes secuenciales puede ser una pista.

Decisión: Si la fragmentación y el llenado son altos, planifica migración de datos o expansión del pool. ZFS es excelente, pero no se desfragmenta por desearlo.

Tres microhistorias del mundo corporativo

Microhistoria 1: El incidente causado por una suposición equivocada

Tuvieron un servidor de archivos ZFS nuevo y dos uplinks 10GbE. El despliegue se veía bien la primera semana, sobre todo porque la prueba fue “copiar un ISO de 20GB una vez” y todos se fueron a casa contentos.

Luego llegó el cierre de trimestre. Finanzas volcó miles de PDFs y hojas de cálculo pequeñas en un share desde una app Windows que insistía en write-through. Los usuarios reportaron copias “que se detenían cada pocos segundos”. El equipo de red no vio saturación, así que se declararon victoriosos y culparon a Windows. El equipo de almacenamiento vio mucha RAM libre y asumió que ARC lo suavizaría. No lo hizo.

La suposición equivocada fue sutil: “Si el pool puede hacer 1GB/s en escrituras secuenciales, puede hacer copias de archivos de oficina”. Son deportes distintos. El ancho de banda secuencial es una vuelta de victoria; la metadata sincrónica es el circuito de obstáculos.

Una vez que alguien ejecutó un simple dd ... conv=fdatasync en el dataset, quedó obvio. La latencia de commit sync era el cuello de botella. El pool era RAIDZ en HDDs. Perfecto para capacidad, terrible para durabilidad de baja latencia.

La solución también fue sutil: no desactivaron sync. Agregaron un SLOG apropiado protegido contra pérdida de energía y quitaron strict sync de los shares que no lo requerían. Finanzas mantuvo sus semánticas; engineering recuperó su velocidad. Los tickets del helpdesk se detuvieron, que es el único KPI que importa cuando estás de guardia.

Microhistoria 2: La optimización que salió mal

Otra empresa tenía copias lentas de directorios personales. Alguien leyó en un foro y decidió que “recordsize más grande = más rápido”. Así que pusieron recordsize=1M en todos los datasets SMB, incluidos directorios personales y árboles de proyectos compartidos.

Las copias de archivos grandes mejoraron ligeramente. Luego las quejas se volvieron raras: guardar documentos pequeños se sentía lento, el acceso a PST de Outlook se volvió inestable y algunas apps empezaron a “no responder” al guardar. El servidor SMB no estaba caído; simplemente hacía trabajo extra.

¿Por qué? Las sobreescrituras parciales en registros grandes pueden crear amplificación de escritura. Un pequeño cambio en un archivo puede desencadenar un read-modify-write de un bloque grande, especialmente cuando la carga es aleatoria y la app hace muchas actualizaciones pequeñas. ZFS es copy-on-write, así que ya hace contabilidad cuidadosa; añadir amplificación es como pedirle que haga malabarismos en una caminadora.

La “optimización” que salió mal también incrementó la agitación de metadata porque los perfiles de usuario generan montones de archivos diminutos y actualizaciones de atributos. Un recordsize mayor no ayudó el camino de metadata en absoluto. Solo empeoró el camino de datos.

El rollback fue disciplinado: separaron datasets por carga. Directorios personales fueron a recordsize 128K, atime off. Los archivos de medios/proyectos grandes se quedaron en 1M. El rendimiento se estabilizó. La lección perduró: afinar no es un buffet donde pones todo lo que parece apetitoso.

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

Un equipo con un cluster ZFS + Samba tenía un hábito poco glamuroso: reportes de scrub semanales y snapshots de rendimiento mensuales. No dashboards para pared ejecutiva. Solo un archivo de texto con zpool status, zpool iostat bajo carga y contadores básicos de errores NIC.

Un martes, los usuarios reportaron que las copias se habían vuelto “espigadas”. El ingeniero de guardia no adivinó. Sacó la línea base y la comparó con los números actuales. El gran cambio: la latencia de escritura en una pata del mirror había subido, y aparecían errores corregibles—lo suficiente para disparar reintentos, no para fallar el disco.

Porque tenían datos de referencia, no pasaron media jornada discutiendo sobre flags de Samba. Reemplazaron el disco durante una ventana de mantenimiento, resilverearon y los stalls de copia desaparecieron.

No pasó nada heroico. Ningún tunable mágico. Solo notar que una “regresión de rendimiento” a menudo es “hardware envejeciendo lentamente”. Esto es lo que la competencia aburrida parece en producción.

Decisiones de ajuste que realmente impactan

1) Decide explícitamente tu postura sobre sync (no dejes que te suceda)

Las cargas SMB pueden ser intensivas en sync, especialmente con ciertas aplicaciones y políticas. Tienes tres opciones:

• Respetar sync y pagarlo: mantener sync=standard, evitar configuraciones de Samba que forcen flushes extra, y desplegar un SLOG real si se necesita.
• Forzar siempre sync: sync=always para shares con cumplimiento estricto. Espera menor throughput; diseña almacenamiento en consecuencia.
• Desactivar sync: sync=disabled es una decisión de negocio para arriesgar perder escrituras reconocidas en corte de energía o crash. Puede ser válido en shares temporales, pero no lo disimules como “rendimiento gratis”. Es un contrato de durabilidad distinto.

2) Separa datasets por carga (un share, un comportamiento)

Un dataset para todo es la forma más rápida de que nada funcione bien. Separa:

• Directorios personales (intensivo en metadata, archivos pequeños)
• Árboles de proyecto de engineering (muchos archivos pequeños, mayormente lectura)
• Archivos de medios (grandes y secuenciales)
• Zonas de caída de aplicaciones (pueden requerir durabilidad estricta)

Luego ajusta propiedades por dataset: recordsize, atime, sync, compresión, comportamiento de ACL.

3) Acierta el recordsize lo suficiente

• Compartidos SMB generales: empieza con recordsize=128K.
• Archivos grandes: considera recordsize=1M si la mayoría de archivos son grandes y secuenciales.
• Bases de datos/VMs sobre SMB: evítalo si puedes; si debes, usa configuraciones especializadas y prueba a fondo. Servir archivos SMB y datastores de VM no es un matrimonio casual.

4) Apaga atime para shares SMB (salvo que tengas una razón real)

atime=on añade escrituras de metadata en lecturas. La mayoría de organizaciones no usa la hora de acceso para nada significativo, y Windows ciertamente no necesita que tu servidor ZFS escriba metadata extra cada vez que alguien abre un archivo.

5) Mantén LZ4 activado por defecto

LZ4 es uno de los pocos “por defecto” que defenderé en producción. A menudo mejora el throughput efectivo y reduce I/O. No lo sobrepienses hasta que tengas evidencia de saturación de CPU.

6) Usa un SLOG real cuando lo necesites (y no escatimes)

Un dispositivo SLOG no es “cualquier SSD”. Necesita baja latencia bajo carga de escrituras sync y protección contra pérdida de energía. Si no, construiste un generador de latencia caro.

7) Samba: evita “strict sync” salvo que lo justifiques

strict sync puede destruir el throughput para cargas que generan muchos puntos de fsync (incluyendo algunos comportamientos de Windows al cerrar archivos). Si necesitas semánticas estrictas, haz que el almacenamiento sea capaz. Si no, no lo pagues.

8) Signing/encryption SMB: limita su alcance

Los equipos de seguridad gustan de políticas globales. Los sistemas de producción gustan de presupuestos. Si signing/encryption debe ser obligatorio, asegura que el host SMB tenga margen de CPU y aceleración criptográfica moderna. Si solo ciertos shares contienen datos sensibles, delimita políticas por share o por segmento de tráfico.

Broma #2: Nada hace un servidor de archivos más rápido que una reunión de políticas que termina con “no cambiamos nada”.

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

1) Síntoma: La copia empieza rápida, luego cae a 0 B/s repetidamente

Causa raíz: Stalls de commit TXG por escrituras síncronas o latencia de flush lenta (sin SLOG, vdevs lentos, pool muy lleno).

Solución: Mide fsync (dd ... conv=fdatasync), verifica configuraciones sync de Samba, añade un SLOG apropiado o rediseña el pool para latencia, recupera espacio.

2) Síntoma: Archivos grandes copian bien; muchos archivos pequeños van lentos

Causa raíz: Carga limitada por metadata (ACLs, xattrs, timestamps) además de I/O aleatorio pequeño.

Solución: atime=off, asegúrate de propiedades adecuadas del dataset, considera espejos para pools intensivos en metadata, verifica que los módulos VFS de Samba no añadan sobrecarga, acepta que esto es IOPS no bandwidth.

3) Síntoma: Velocidad tope ~110 MB/s en “10GbE”

Causa raíz: Cliente/servidor negociado a 1GbE, hashing LACP malo, o flujo TCP único sin multichannel.

Solución: Revisa velocidad de enlace con ethtool, valida configuración del switch, prueba SMB multichannel y verifica que el cliente no esté en un segmento 1GbE.

4) Síntoma: Rendimiento peor tras activar signing o encriptación SMB

Causa raíz: Cuello de botella de CPU en crypto/signing, puntos calientes single-thread, colas RSS insuficientes.

Solución: Mide CPU por núcleo durante la transferencia, habilita multiqueue/RSS, actualiza CPU, delimita signing/encryption o usa hardware con aceleración.

5) Síntoma: Copias se cuelgan intermitentemente por “exactamente unos segundos”

Causa raíz: Retransmisiones de red, bufferbloat o congestión del switch; a veces la temporización de TXG alinea con las pausas percibidas.

Solución: Revisa retransmisiones (netstat -s), drops de interfaz y contadores del switch. Si está limpio, vuelve a la latencia de almacenamiento y sync.

6) Síntoma: Un share es lento; otro en el mismo servidor va bien

Causa raíz: Mismatch en propiedades del dataset (sync=always, recordsize raro, atime on), diferencias en config Samba (strict sync, módulos VFS) o cuotas/reservas afectando asignación.

Solución: Compara salidas de zfs get y bloques de testparm -sv para ambos shares. Normaliza intencionalmente.

7) Síntoma: “Windows dice que tomará 2 horas” pero el servidor parece inactivo

Causa raíz: Escaneo en el cliente (antivirus, indexación), sobrecarga de archivos pequeños o el cliente esperando por operaciones metadata por archivo.

Solución: Reproduce con un cliente limpio, prueba con opciones de robocopy y confirma métricas del servidor durante la operación. No ajustes servidores para compensar endpoints problemáticos.

Listas de verificación / plan paso a paso

Paso a paso: arreglar copias SMB “rápido y luego cero” en ZFS

1. Confirma salud del pool: zpool status -v. Si está degradado o con errores, detente y arregla discos.
2. Revisa llenado del pool: zfs list. Si >85% usado, planifica recuperación/expansión de espacio.
3. Identifica dataset y propiedades: zfs get recordsize,atime,sync,compression.
4. Inspecciona configuración del share Samba: testparm -sv buscando strict sync, ajustes aio, módulos VFS.
5. Mide latencia sync: prueba servidor-side dd ... conv=fdatasync. Si es lenta, es tu principal sospechosa.
6. Comprueba presencia/rendimiento de SLOG: zpool status para logs y asegurarse de que la clase de dispositivo sea apropiada.
7. Observa latencia de disco bajo carga: iostat -x y zpool iostat mientras reproduces.
8. Verifica salud de red: ip -s link, retransmisiones (netstat -s) y velocidad de enlace (ethtool).
9. Aplica un cambio a la vez: por ejemplo, desactiva strict sync en un share de prueba o añade SLOG; luego repite la misma transferencia y compara.
10. Anota el resultado: captura latencia, throughput y si los stalls desaparecieron. La memoria falla; los tickets no.

Checklist base (lo aburrido que agradecerás)

• Scrub semanal programado; reportes de scrub revisados.
• Snapshot mensual de: zpool status, propiedades clave de zfs get, ip -s link y una prueba repetible de throughput + fsync.
• Layout de datasets documentado por categoría de carga.
• Política explícita sobre sync: qué shares requieren garantías de durabilidad.
• Control de cambios para la configuración de Samba; no “fixes de una línea” en producción a las 2am.

Preguntas frecuentes

1) ¿Por qué Explorer muestra velocidad alta y luego 0 B/s?

Explorer reporta basado en buffering y aceptación a corto plazo. ZFS y Samba pueden aceptar datos rápido y luego hacer una pausa mientras comprometen escrituras sync o TXGs. Mide latencia del servidor.

2) ¿Es robocopy más rápido que Explorer?

A veces. La ventaja mayor es que robocopy es más predecible y scriptable, y expone reintentos y comportamiento por archivo. No arreglará la latencia sync del servidor.

3) ¿Debo poner sync=disabled para hacerlo rápido?

Sólo si aceptas perder escrituras reconocidas en corte de energía o crash. Para shares temporales puede ser aceptable. Para datos de negocio es una degradación de durabilidad, no un truco de tuning.

4) ¿Necesito un SLOG para SMB?

Si tu carga genera muchas escrituras sync (o las configuraciones de Samba fuerzan flushing estricto), un buen SLOG puede ser transformador. Si la carga es mayormente async, un SLOG no ayudará mucho.

5) ¿Qué recordsize debo usar para shares SMB?

Empieza en 128K para shares de propósito general. Usa 1M para archivos grandes secuenciales. Evita cambios globales; separa datasets por carga.

6) ¿Activar LZ4 ralentiza?

Normalmente no, y con frecuencia acelera al reducir I/O. Si la CPU ya está saturada (encryption/signing, carga intensa), mide antes de decidir.

7) ¿RAIDZ es malo para SMB?

No “malo”, pero RAIDZ es menos amigable con escrituras aleatorias pequeñas y cargas intensivas en metadata que los espejos. Si tu caso SMB son muchos archivos pequeños y comportamiento sync, los mirrors suelen ganar en latencia.

8) ¿Por qué un share SMB es lento y otros están bien?

Propiedades diferentes de dataset o opciones de share Samba. Busca sync=always, atime=on, recordsize extraño o strict sync activado en un solo share.

9) ¿SMB Multichannel lo arregla todo?

No. Puede aumentar throughput y resiliencia, pero no arreglará latencia de almacenamiento o stalls por sync. Además requiere NIC, driver y soporte del cliente correctos.

10) ¿Cómo sé si estoy limitado por CPU?

Durante la transferencia, uno o más núcleos estarán consistentemente altos, a menudo en smbd o en networking/crypto del kernel. Mientras tanto, discos y NICs no estarán saturados. Ese es tu indicio.

Próximos pasos que puedes ejecutar esta semana

Haz estos en orden. Cada paso aclara una decisión, y ninguno requiere fe.

1. Elige una prueba reproducible (un archivo grande y una carpeta de “muchos archivos pequeños”) y mantenla constante.
2. Ejecuta la guía rápida de diagnóstico y captura salidas: zpool iostat, iostat -x, ip -s link, netstat -s, smbstatus.
3. Prueba o elimina la latencia sync con la prueba servidor-side dd ... conv=fdatasync en el dataset.
4. Separa datasets por carga si no lo has hecho. Ajusta atime=off y un recordsize sensato por categoría.
5. Arregla el verdadero cuello de botella: añade un SLOG apropiado para shares sync-heavy, recupera espacio si el pool está demasiado lleno, o atiende problemas de CPU/red si la evidencia apunta ahí.
6. Escribe un runbook de una página con tus comandos base y salidas “normales”. El tú del futuro le comprará café al tú del pasado.

El objetivo no es un gráfico perfecto. El objetivo es rendimiento predecible bajo el contrato de durabilidad que realmente quieres ofrecer. Una vez que eliges ese contrato a propósito, ZFS y SMB dejan de ser misteriosos y pasan a ser… simplemente exigentes.

Por qué cambiaron las CPU: física, dinero y el fin de “simplemente reducir tamaño”

Durante décadas, podías tratar el progreso de las CPU como una suscripción predecible: cada generación era más densa, más rápida y (en su mayoría) más barata por unidad de cómputo. Esa era no terminó con un comunicado espectacular. Terminó con mil compromisos pequeños: corriente de fuga, coste de litografía, variabilidad y la incómoda verdad de que los cables no escalan como lo hacen los transistores.

Cuando escuches “chiplets” y “apilamiento 3D”, no lo traduzcas como “ingeniería ingeniosa”. Tradúcelo como: las viejas suposiciones económicas y físicas se rompieron, así que el empaquetado se convirtió en la nueva arquitectura. Movemos la innovación del interior de un dado hacia entre dados.

Hechos y contexto histórico (lo que realmente te ayuda a razonar)

• Hecho 1: El escalado de Dennard (densidad de potencia constante al reducir transistores) se detuvo a mediados de los 2000, forzando la paralización del crecimiento de frecuencia y empujando diseños multicore.
• Hecho 2: La latencia de interconexión ha sido un cuello de botella principal durante años; los cables en el chip no se vuelven proporcionalmente más rápidos con cada nodo, así que “dado más grande” significa más tiempo moviendo bits.
• Hecho 3: Los límites de retícula limitan cuán grande puede ser una exposición de litografía; los dados muy grandes se convierten en pesadillas de rendimiento salvo que los dividas o los hilvanes.
• Hecho 4: La industria ha usado módulos multi-dado durante mucho tiempo (piensa: paquetes de dos dados tempranos, módulos para servidores), pero los chiplets actuales están mucho más estandarizados y son críticos para el rendimiento.
• Hecho 5: High Bandwidth Memory (HBM) se volvió práctica apilando dados DRAM y conectándolos con TSVs, demostrando que la integración vertical puede vencer al ancho de banda tradicional de DIMM.
• Hecho 6: El apilamiento de caché 3D en CPUs de consumo mostró una lección concreta: añadir SRAM verticalmente puede mejorar el rendimiento sin agrandar el dado lógico más caliente.
• Hecho 7: Núcleos heterogéneos (concepto big/little) han existido en móviles por años; ahora son comunes en servidores porque la potencia y las térmicas —no la frecuencia máxima— definen el rendimiento sostenido.
• Hecho 8: El empaquetado avanzado (interposers 2.5D, puentes de silicio, fan-out) es hoy un diferenciador competitivo, no un detalle de fabricación en el backend.

Conclusión operativa: la próxima ganancia de rendimiento del 10–15 % es menos probable que provenga de una nueva instrucción y más probable que provenga de mejor localidad, jerarquías de memoria más inteligentes y enlaces entre dados más apretados. Si tu carga es sensible a la varianza de latencia, necesitas tratar el empaquetado y la topología como tratas el enrutamiento de red.

Chiplets, interconexiones y por qué “socket” ya no significa lo que crees

Una CPU chiplet es un paquete que contiene múltiples dados, cada uno especializándose en algo: núcleos, caché, controladores de memoria, E/S, aceleradores, a veces incluso procesadores de seguridad. El paquete es el producto. La “CPU” ya no es una losa única; es un pequeño sistema distribuido que vive bajo un disipador.

Los chiplets existen por tres razones directas:

1. Rendimiento de fabricación (yield): los dados más pequeños tienen mejor yield; los defectos no matan un dado gigante entero.
2. Mezcla de nodos de proceso: lógica rápida en un nodo avanzado, E/S en un nodo más económico y maduro.
3. Agilidad de producto: reutilizar un dado de IO válido en varios SKUs; variar conteos de núcleos y mosaicos de caché sin rehacerlo todo.

La interconexión es ahora arquitectura

En un dado monolítico, los caminos núcleo–caché y núcleo–memoria son mayormente “internos”. En chiplets, esos caminos pueden atravesar una tela entre dados. La interconexión tiene ancho de banda, latencia y características de congestión, y puede introducir efectos topológicos que se parecen sospechosamente a un problema de red —excepto que no puedes tcpdumpear para solucionarlo.

Los paquetes modernos usan telas propietarias, y hay un empuje industrial hacia estándares interoperables die‑to‑die como UCIe. El punto clave no es el acrónimo. Es que los enlaces entre dados se tratan como E/S de alta velocidad: serializados, sincronizados, gestionados en potencia, entrenados, a veces reintentados. Eso significa que el estado del enlace, contadores de error y estados de energía pueden afectar el rendimiento de maneras que parecen “aleatorias” a menos que las midas.

Broma #1: Los chiplets son como microservicios: a todos les encanta la flexibilidad hasta que tienes que depurar la latencia a través de fronteras que creaste a propósito.

NUMA no era nuevo. Simplemente dejaste de respetarlo.

Las CPU chiplet convierten cada servidor en una máquina NUMA más matizada. A veces los “nodos NUMA” mapean a controladores de memoria; a veces a complejos de núcleos; a veces a ambos. En cualquier caso, la localidad importa: qué núcleo accede a qué memoria, qué porción de la caché de último nivel está más cerca y con qué frecuencia cruzas la interconexión.

Si tu playbook de rendimiento todavía empieza y termina con “añadir núcleos” y “fijar hilos”, chocarás con el nuevo muro: contención de interconexión y jerarquía de memoria. El paquete de la CPU ahora tiene patrones de tráfico internos, y tu carga puede crear puntos calientes.

Apilamiento 3D: ancho de banda vertical, problemas verticales

El apilamiento 3D es el uso de múltiples dados apilados verticalmente con conexiones densas (a menudo through‑silicon vias, micro-bumps o hybrid bonding). Se usa para caché, DRAM (HBM) y cada vez más para arreglos lógica‑sobre‑lógica.

¿Por qué apilar?

• Ancho de banda: las conexiones verticales pueden ser mucho más densas que el enrutamiento borde‑a‑borde en el paquete.
• Latencia: la menor distancia física puede reducir el tiempo de acceso para ciertas estructuras (especialmente caché).
• Eficiencia de área: puedes añadir capacidad sin crecer la huella 2D de un dado lógico caliente.

Pero no obtienes algo por nada. El apilamiento 3D introduce un triángulo operativo feo: térmicas, yield y fiabilidad.

Caché apilada: por qué funciona

Apilar SRAM sobre un dado de cómputo te da una gran caché de último nivel sin hacer el dado de cómputo enorme. Eso puede ser una ganancia masiva para cargas con conjuntos de trabajo justo por encima de los tamaños de caché tradicionales: muchos juegos, algunos flujos EDA, ciertas bases de datos en memoria, almacenes clave‑valor con claves calientes y canalizaciones analíticas con escaneos repetidos.

Desde la perspectiva operativa, la caché apilada cambia dos cosas:

1. El rendimiento se vuelve más bimodal. Si tu carga cabe en caché, eres un héroe. Si no, vuelves a DRAM y la mejora se evapora.
2. El margen térmico se vuelve precioso. El silicio extra encima del dado de cómputo afecta el flujo de calor; el comportamiento turbo y las frecuencias sostenidas pueden cambiar de maneras que aparecen como varianza en la latencia.

HBM: el truco de ancho de banda con costo

HBM apila dados DRAM y los coloca cerca del dado de cómputo (a menudo vía interposer). Esto entrega un ancho de banda enorme comparado con DIMMs tradicionales, pero la capacidad por pila es limitada y el coste es alto. También cambia fallos y observabilidad: los errores de memoria pueden mostrarse de forma distinta y la planificación de capacidad se vuelve otro deporte.

El empaquetado 3D y 2.5D también está forzando una nueva regla de diseño: tu software debe entender niveles. HBM vs DDR, memoria cercana vs memoria lejana, caché en paquete vs caché en dado. “Simplemente asigna memoria” se convierte en una decisión de rendimiento.

Broma #2: Apilar dados es genial hasta que recuerdas que el calor también se apila, y a diferencia de tu backlog no puede posponerse.

El verdadero enemigo: bytes, no flops

La mayoría de los sistemas de producción no están limitados por el rendimiento aritmético bruto. Están limitados por mover datos: de memoria a caché, de caché al núcleo, del núcleo al NIC, del almacenamiento a la memoria y de vuelta. Los chiplets y el apilamiento 3D son reconocimientos industriales de que la memoria y la interconexión son el evento principal.

Aquí es donde los instintos de SRE ayudan. Cuando el paquete de la CPU se convierte en una tela, los cuellos de botella parecen:

• Alta IPC pero bajo rendimiento (esperando memoria o por contención de locks).
• CPU no ocupada pero latencia alta (stalls, fallos de caché, memoria remota).
• El rendimiento cae tras escalar (el tráfico entre chiplets crece superlinealmente).

Qué cambia con chiplets y apilamiento

La localidad de memoria ya no es opcional. En un dado monolítico grande, el acceso “remoto” aún puede ser bastante rápido. En chiplets, el acceso remoto puede atravesar saltos de tela y competir con otro tráfico. En un SKU con caché apilada, la caché “local” puede ser mayor pero la penalización por fallarla puede ser más visible debido al cambio en frecuencia/térmicas.

El ancho de banda no es uniforme. Algunos dados tienen acceso más cercano a ciertos controladores de memoria. Algunos núcleos comparten slices de caché más estrechamente. La topología puede recompensar una buena planificación y castigar una programación ingenua.

La varianza de latencia se vuelve normal. Estados de gestión de energía, clock gating en la tela y algoritmos de boost pueden cambiar las latencias internas. Tu p99 lo notará antes que los promedios.

Térmicas y energía: el paquete es el nuevo campo de batalla

En el papel, compras una CPU con un TDP y una frecuencia boost y das el asunto por cerrado. En realidad, las CPUs modernas son sistemas gestionados por energía que negocian constantemente las frecuencias basadas en temperatura, corriente y características de la carga. Los chiplets y los apilamientos 3D complican esa negociación.

Puntos calientes y gradientes térmicos

Con chiplets, no tienes un perfil térmico uniforme. Tienes puntos calientes donde los núcleos son densos, dados de IO separados que corren más fríos y a veces dados apilados que impiden la extracción de calor del dado de cómputo debajo. En cargas de producción de larga duración, las frecuencias sostenidas importan más que los picos.

Dos consecuencias operativas:

• Los benchmarks mienten con más frecuencia. Los benchmarks cortos alcanzan el boost; la producción llega al estado estable y a los límites de potencia.
• La refrigeración es rendimiento. Un disipador o flujo de aire marginal no solo causará throttling; causará varianza, que es más difícil de depurar.

Fiabilidad: más conexiones, más lugares para echarse a perder

Más dados y más interconexiones significan más puntos potenciales de fallo: micro-bumps, TSVs, sustratos de paquete y entrenamiento de enlaces. Los proveedores diseñan para esto, por supuesto. Pero en campo lo verás como errores corregidos, enlaces degradados o incidentes de “un host está raro”.

Un aforismo operativo útil, parafraseando una idea de una voz notable en fiabilidad: Los sistemas complejos fallan de formas complejas; reduce lo desconocido y mide las cosas correctas. (idea parafraseada, inspirada en el pensamiento de ingeniería de fiabilidad a menudo atribuido a John Allspaw)

Traducción: no asumas uniformidad entre hosts, y no asumas que dos sockets se comportan igual solo porque el SKU coincide.

Qué significa esto para SREs: rendimiento, fiabilidad y vecinos ruidosos

No necesitas convertirte en ingeniero de empaquetado. Necesitas dejar de tratar la “CPU” como un recurso escalar único. En un mundo chiplet + apilamiento, gestionas:

• Cómputo topológico (los núcleos no están a igual distancia de memoria y caché)
• Capacidad de interconexión (la tela interna puede saturarse)
• Margen térmico (frecuencias sostenidas, throttling y p99)
• Política de energía (limitación, turbo e interacciones con el scheduler)

La observabilidad debe ampliarse

El monitoreo tradicional del host —%CPU, load average, memoria usada— cada vez fallará más al explicar cuellos de botella. Necesitas al menos un manejo básico de:

• Localidad NUMA (¿están alineados hilos y memoria?)
• Comportamiento de caché (fallos LLC, presión de ancho de banda)
• Frecuencia y throttling (¿estás limitado por potencia?)
• Colocación del scheduler (¿Kubernetes o systemd movieron tu carga entre nodos?)

Y sí, esto es molesto. Pero es menos molesto que un cuarto de los casos de “actualizamos CPUs y empeoró”.

Guion de diagnóstico rápido: encuentra el cuello de botella en minutos

Este es el flujo de triaje que uso cuando un servicio se vuelve más lento en una nueva plataforma chiplet/apilada, o se vuelve más lento después de escalar. El objetivo no es la causa raíz perfecta. El objetivo es tomar la decisión siguiente correcta rápidamente.

Primero: determina si estás limitado por cómputo, memoria o “tela”

1. Revisa la frecuencia de CPU y el throttling: si los relojes están bajos bajo carga, estás limitado por potencia/térmicas.
2. Revisa el ancho de banda de memoria y la presión de fallos de caché: si los fallos LLC y el ancho de banda son altos, estás limitado por memoria.
3. Revisa la localidad NUMA: si el acceso a memoria remota es alto, probablemente estás limitado por topología/scheduler.

Segundo: confirma topología y colocación

1. Verifica nodos NUMA y mapeo CPU‑a‑nodo.
2. Verifica afinidad de procesos y política de memoria.
3. Comprueba si la carga está rebotando entre nodos (migraciones del scheduler).

Tercero: aísla una variable y vuelve a ejecutar

1. Fija la carga a un nodo NUMA; compara p95/p99.
2. Forza la asignación de memoria local; compara rendimiento.
3. Aplica una política de energía conservadora; compara la varianza.

Si no puedes reproducir un cambio significativo controlando colocación y estado de energía, el problema probablemente sea de capa superior (locks, GC, E/S), y deberías dejar de culpar al paquete de la CPU. Las CPUs modernas son complicadas, pero no mágicas.

Tareas prácticas con comandos: qué ejecutar, qué significa, qué decidir

Estas son tareas reales que puedes ejecutar en hosts Linux para entender comportamientos relacionados con chiplets/apilamiento 3D. Los comandos son deliberadamente aburridos. Las herramientas aburridas te mantienen honesto.

Tarea 1: Mapea la topología NUMA rápidamente

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Thread|Core|NUMA|CPU\(s\)'
CPU(s):                               128
Model name:                           AMD EPYC 9xx4
Thread(s) per core:                   2
Core(s) per socket:                   64
Socket(s):                            1
NUMA node(s):                         8

Qué significa la salida: Tienes 8 nodos NUMA en un solo socket. Eso es una topología tipo chiplet: múltiples dominios de memoria y saltos de interconexión dentro de un paquete.

Decisión: Si la latencia importa, planifica fijar servicios clave dentro de un nodo NUMA y mantener la memoria local. El scheduling por defecto puede ser “aceptable”, pero “aceptable” es como muere el p99.

Tarea 2: Ver qué CPUs pertenecen a cada nodo NUMA

cr0x@server:~$ numactl --hardware
available: 8 nodes (0-7)
node 0 cpus: 0-15
node 0 size: 64000 MB
node 0 free: 61234 MB
node 1 cpus: 16-31
node 1 size: 64000 MB
node 1 free: 60110 MB
node 2 cpus: 32-47
node 2 size: 64000 MB
node 2 free: 59872 MB
node 3 cpus: 48-63
node 3 size: 64000 MB
node 3 free: 62155 MB
node 4 cpus: 64-79
node 4 size: 64000 MB
node 4 free: 60990 MB
node 5 cpus: 80-95
node 5 size: 64000 MB
node 5 free: 61801 MB
node 6 cpus: 96-111
node 6 size: 64000 MB
node 6 free: 61644 MB
node 7 cpus: 112-127
node 7 size: 64000 MB
node 7 free: 62002 MB

Qué significa la salida: Cada nodo NUMA tiene un rango de CPU y una porción de memoria. Si tu proceso corre en CPUs del nodo 0 pero asigna memoria desde el nodo 6, pagará un peaje de tela en cada acceso remoto.

Decisión: Para servicios sensibles a la latencia, alinea la afinidad de CPU y la política de memoria. Para trabajos de throughput, puede que prefieras intercalar para ancho de banda.

Tarea 3: Comprueba si el kernel está registrando problemas de localidad NUMA

cr0x@server:~$ numastat -p 1 3
Per-node process memory usage (in MBs) for PID 1 (systemd)
Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
----- ----- ----- ----- ----- ----- ----- ----- -----
Numa_Hit      12     10      9      8      9     10      8      9    75
Numa_Miss      1      0      0      0      0      0      0      0     1
Numa_Foreign   0      0      0      0      0      0      0      0     0
Interleave_Hit 0      0      0      0      0      0      0      0     0
Local_Node    12     10      9      8      9     10      8      9    75
Other_Node     1      0      0      0      0      0      0      0     1

Qué significa la salida: Para PID 1 está bien. Para tu servicio real, si Other_Node es grande, estás pagando penalizaciones remotas.

Decisión: Si el acceso remoto es alto y la latencia tail es mala, fija y localiza. Si tu objetivo es throughput y estás limitado por ancho de banda, considera intercalar.

Tarea 4: Verifica el comportamiento de la frecuencia de CPU bajo carga

cr0x@server:~$ sudo turbostat --Summary --quiet --show CPU,Avg_MHz,Busy%,Bzy_MHz,PkgTmp,PkgWatt --interval 5
CPU  Avg_MHz  Busy%  Bzy_MHz  PkgTmp  PkgWatt
-    2850     62.10  4588     86      310.12

Qué significa la salida: Los núcleos ocupados están corriendo alto (Bzy_MHz), la temperatura del paquete es alta y la potencia es sustancial. Si Bzy_MHz colapsa con el tiempo mientras Busy% se mantiene alto, probablemente estés limitado por potencia/térmicas.

Decisión: Para cargas sostenidas, ajusta capado de potencia, refrigeración o reduce la concurrencia. No persigas números de boost de una sola ejecución.

Tarea 5: Confirma que la política de energía (governor) no te sabotea

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

Qué significa la salida: El governor está en performance. Si está en powersave en un host sensible a la latencia, básicamente estás pidiendo jitter.

Decisión: Ajusta la política apropiada por rol de clúster. Un clúster batch puede ahorrar energía; un clúster OLTP no debe disfrazarse de portátil.

Tarea 6: Medir migraciones del scheduler (un silencioso asesino NUMA)

cr0x@server:~$ pidstat -w -p $(pgrep -n myservice) 1 5
Linux 6.5.0 (server)  01/12/2026  _x86_64_  (128 CPU)

01:10:01 PM   UID       PID   cswch/s nvcswch/s  Command
01:10:02 PM  1001     43210   120.00     15.00  myservice
01:10:03 PM  1001     43210   135.00     20.00  myservice
01:10:04 PM  1001     43210   128.00     18.00  myservice

Qué significa la salida: Los cambios de contexto son moderados. Si además ves migraciones frecuentes de CPU (vía perf o schedstat), puedes perder localidad de caché entre chiplets.

Decisión: Considera fijar CPUs para los hilos más calientes, o ajusta tu runtime (hilos de GC, conteos de workers) para reducir churn.

Tarea 7: Comprobar presión de ancho de banda de memoria con pcm-memory (si está instalado)

cr0x@server:~$ sudo pcm-memory 1 -csv
Time,Ch0Read,Ch0Write,Ch1Read,Ch1Write,SystemRead,SystemWrite
1.00,12.3,5.1,11.8,4.9,198.4,82.1
2.00,12.5,5.0,12.1,4.8,201.0,80.9

Qué significa la salida: El ancho de banda de lectura/escritura del sistema es alto. Si está cerca de los límites de la plataforma durante tu incidente, estás atascado por memoria, no por CPU.

Decisión: Reduce el tráfico de memoria: arregla el layout de datos, disminuye copias, aumenta la tasa de aciertos de caché o migra a una plataforma con caché apilada/HBM si tu conjunto de trabajo encaja.

Tarea 8: Observar señales de fallos de caché y stalls con perf

cr0x@server:~$ sudo perf stat -p $(pgrep -n myservice) -e cycles,instructions,cache-misses,branches,branch-misses -a -- sleep 10
 Performance counter stats for 'system wide':

    38,112,001,220      cycles
    52,880,441,900      instructions              #    1.39  insn per cycle
       902,110,332      cache-misses
     9,221,001,004      branches
       112,210,991      branch-misses

      10.002113349 seconds time elapsed

Qué significa la salida: Muchos fallos de caché. La IPC es decente, pero los fallos aún pueden dominar el tiempo de muro según la carga. En CPUs chiplet, los fallos pueden convertirse en tráfico de tela y accesos a memoria remota.

Decisión: Si los fallos de caché correlacionan con picos de latencia, prioriza localidad: fija hilos, reduce contención de estado compartido y prueba SKUs con caché apilada cuando el conjunto de trabajo esté justo por encima del LLC.

Tarea 9: Comprobar errores de memoria y tormentas de errores corregidos

cr0x@server:~$ sudo ras-mc-ctl --summary
Memory controller events summary:
  Corrected errors: 24
  Uncorrected errors: 0
  No DIMM labels were found

Qué significa la salida: Hay errores corregidos. Una tasa creciente puede causar degradación del rendimiento y comportamiento impredecible, y en plataformas de empaquetado avanzado quieres notarlo pronto.

Decisión: Si los errores corregidos aumentan, programa mantenimiento: volver a asentar o reemplazar DIMMs, actualizar firmware o retirar el host. No esperes a que los errores no corregidos te enseñen humildad.

Tarea 10: Validar salud de enlaces/PCIe (el dado de IO también forma parte del relato)

cr0x@server:~$ sudo lspci -vv | sed -n '/Ethernet controller/,+25p' | egrep 'LnkSta:|LnkCap:'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s (ok), Width x16 (ok)

Qué significa la salida: El enlace está funcionando a la velocidad/ancho esperados. Si ves enlaces downtrained, el rendimiento de E/S cae y los ciclos de CPU se desperdician en overhead de interrupciones/paquetes.

Decisión: Los enlaces downtrained provocan: revisa risers, configuraciones BIOS, firmware y el asiento físico. No “optimices” software alrededor de hardware roto.

Tarea 11: Confirmar distribución de interrupciones (evita congestión IRQ en un solo núcleo)

cr0x@server:~$ cat /proc/interrupts | egrep 'eth0|mlx|ens' | head
  55:   10223342          0          0          0   IR-PCI-MSI 524288-edge      ens3f0-TxRx-0
  56:          0    9981221          0          0   IR-PCI-MSI 524289-edge      ens3f0-TxRx-1
  57:          0          0    9875522          0   IR-PCI-MSI 524290-edge      ens3f0-TxRx-2

Qué significa la salida: Las interrupciones están repartidas entre CPUs. Si todas las interrupciones caen en una CPU de un nodo NUMA mientras tu carga corre en otro lugar, tendrás tráfico entre nodos y jitter.

Decisión: Fija las IRQs cerca del nodo NUMA del NIC y cerca de los hilos del servicio que consumen paquetes. La localidad también aplica para E/S.

Tarea 12: Comprobar la política de memoria y ejecutar una prueba localmente

cr0x@server:~$ numactl --cpunodebind=2 --membind=2 ./bench --duration 30
throughput=118223 ops/s
p99_latency_ms=3.4

Qué significa la salida: Forzaste CPU y memoria al nodo 2. Compara esto con resultados sin fijar. Un delta grande indica penalizaciones NUMA/tela.

Decisión: Si fijar mejora el p99 de forma material, implementa colocación (CPUAffinity en systemd, topology manager de Kubernetes o fijación a nivel de carga) en lugar de perseguir micro‑optimizaciones.

Tarea 13: Inspeccionar hugepages e indicadores de presión TLB

cr0x@server:~$ grep -E 'HugePages_Total|HugePages_Free|Hugepagesize' /proc/meminfo
HugePages_Total:    4096
HugePages_Free:     3900
Hugepagesize:       2048 kB

Qué significa la salida: Hay hugepages disponibles. En cargas intensivas de memoria, las hugepages pueden reducir fallos de TLB, lo cual importa más cuando la latencia de memoria ya es mayor por accesos remotos.

Decisión: Si el profiling muestra presión TLB, activa hugepages y valida el impacto. No hagas cargo‑cult: mide.

Tarea 14: Detectar throttling y razones de límite de potencia (ejemplo Intel via RAPL)

cr0x@server:~$ dmesg | egrep -i 'thrott|powercap|rapl' | tail -n 5
[ 8123.221901] intel_rapl: power limit changed to 210W
[ 8123.222110] CPU0: Package power limit exceeded, capping frequency

Qué significa la salida: El sistema está capando potencia. Tu benchmark puede haber corrido antes del cap; las ejecuciones de producción durante él.

Decisión: Alinea configuraciones BIOS/firmware de potencia con la intención de la carga. Si limitas por presupuesto de centro de datos, ajusta los SLOs y afina la concurrencia.

Tres mini-historias corporativas de la era chiplet

Mini‑historia 1: El incidente causado por una suposición errónea

Una compañía SaaS de tamaño medio migró una capa API sensible a latencia a servidores nuevos. Mismo conteo de cores que antes, frecuencias boost anunciadas más altas y una cifra llamativa de L3 que parecía dinero gratis. El despliegue fue conservador: canary al 5 %, métricas bien, luego 25 %, luego 50 %.

Alrededor de la mitad de la flota, la latencia p99 comenzó a oscilar. No subir de forma suave: oscilaba. Las gráficas tenían un patrón en sierra que hacía a la gente discutir sobre patrones de tráfico y GC. La utilización de CPU se mantuvo moderada. La red parecía limpia. El almacenamiento estaba tranquilo. El canal de incidentes se llenó con la peor frase en operaciones: “Nada parece estar mal”.

La suposición errónea: trataron la CPU como uniforme y asumieron que si la CPU% promedio estaba bien, la CPU no era el cuello de botella. En realidad, la carga se estaba programando a través de nodos NUMA y asignando memoria de forma remota frecuentemente debido al comportamiento del runtime y la libertad del scheduler de contenedores para mover tareas. Los accesos remotos no eran catastróficos; eran variables, lo que destruyó la latencia tail.

Lo probaron fijando el servicio a un solo nodo NUMA y forzando asignación local en una prueba. El p99 se estabilizó de inmediato y la sierra desapareció. La solución no fue glamurosa: scheduling consciente de topología, fijado de CPU para los pods más calientes y una política de memoria deliberada. También dejaron de sobrecargar pods sensibles a latencia y batch en el mismo socket. “Más utilización” no era el objetivo; la latencia predecible sí lo era.

Mini‑historia 2: La optimización que salió mal

Una fintech ejecutaba un motor de riesgo que escaneaba un gran dataset en memoria repetidamente. Compraron un SKU con caché apilada porque un benchmark del proveedor mostró una gran mejora. Las pruebas tempranas fueron prometedoras. El throughput mejoró. Todos celebraron. Entonces hicieron lo que las empresas hacen: “optimizaron”.

El equipo aumentó agresivamente el paralelismo, asumiendo que la caché extra mantendría la escalabilidad. También activaron una política turbo más agresiva en BIOS para perseguir aceleraciones de corta duración. En staging, la carga terminó más rápido—la mayoría de las veces.

En producción, la optimización falló de dos maneras. Primero, los hilos extra aumentaron el tráfico entre chiplets porque la carga tenía una estructura compartida que no estaba particionada limpiamente. La interconexión se congestinó. Segundo, la política turbo elevó las temperaturas rápido, causando throttling térmico a mitad de ejecución. El sistema no solo se ralentizó; se volvió impredecible. Algunas ejecuciones terminaron rápido; otras golpearon throttling y se arrastraron.

La solución fue casi aburrida: reducir el paralelismo hasta un punto donde la localidad se mantuviera alta, particionar el dataset con más cuidado y establecer una política de energía optimizada para frecuencia sostenida en lugar de pico boost. La caché apilada aún ayudó—pero solo cuando el software respetó la topología y el envelope térmico. La lección: más caché no excusa un mal escalado.

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

Un gran equipo de plataforma corporativa estandarizó una “checklist de bring‑up de hardware” para nuevas generaciones de CPU. Incluía baselines de BIOS/firmware, versiones de microcode, verificación de topología NUMA y un conjunto fijo de pruebas smoke de perf/latencia fijadas a nodos específicos.

Cuando llegó un lote de nuevos servidores, las pruebas detectaron una regresión sutil: el ancho de banda de memoria era menor de lo esperado en un nodo NUMA y la latencia p99 bajo una carga sintética mixta era peor. Nada fallaba abiertamente. La mayoría de equipos lo habría declarado “dentro de la varianza” y seguido.

La checklist forzó la escalada. Resultó que una configuración BIOS relacionada con interleaving de memoria y gestión de potencia difería del baseline por un cambio en el valor por defecto del proveedor. Los servidores estaban técnicamente “funcionando”, pero no funcionaban igual que el resto de la flota. Esa discrepancia se habría convertido en una pesadilla de guardia más tarde, porque el comportamiento heterogéneo dentro de un grupo autoscalado convierte incidentes en juegos de probabilidad.

Arreglaron el baseline, reimaginizaron los hosts, volvieron a ejecutar las mismas pruebas fijadas y obtuvieron los resultados esperados. Sin heroicidades. Sin incidentes nocturnos. Solo disciplina operativa: medir, estandarizar y negarse a aceptar variancia silenciosa en un mundo donde los paquetes son pequeños sistemas distribuidos.

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

1) Síntoma: p99 sube al escalar a más cores

Causa raíz: Contención entre chiplets y aumento de accesos a memoria remota al dispersar hilos entre nodos NUMA; estructuras de datos compartidas amplifican el tráfico.

Solución: Particionar estado, reducir compartición entre hilos, fijar workers críticos dentro de un nodo NUMA y usar scheduling consciente de topología.

2) Síntoma: Utilización de CPU moderada pero throughput bajo

Causa raíz: Stalls de memoria (fallos LLC, latencia DRAM), congestión de la tela o migraciones frecuentes se ocultan detrás de “no ocupado”.

Solución: Usa perf stat y herramientas de ancho de banda de memoria; revisa numastat; fija y localiza; reduce churn del asignador y las copias.

3) Síntoma: Nuevos servidores son más rápidos en benchmarks pero peores en producción

Causa raíz: Los benchmarks alcanzan boost clocks y estados de caché caliente; la producción alcanza límites de potencia sostenida y cargas mixtas.

Solución: Prueba con ejecuciones en estado estable, incluye métricas p99 y valida bajo concurrencia y condiciones térmicas realistas.

4) Síntoma: Un host en la pool es consistentemente raro

Causa raíz: Enlace PCIe downtrained, canal de memoria degradado, tormenta de errores corregidos o deriva de BIOS afectando potencia/topología.

Solución: Revisa lspci -vv, resúmenes RAS, versiones de microcode/BIOS; pone en cuarentena y remedia en lugar de ajustar alrededor del problema.

5) Síntoma: Jitter de latencia aparece tras habilitar funciones “ahorro de energía”

Causa raíz: C‑states agresivos, clock gating en la tela, escalado de frecuencia o límites de paquete causan comportamiento variable de wake/boost.

Solución: Usa governor de performance para tiers de latencia, ajusta estados de energía en BIOS y valida con turbostat bajo carga real.

6) Síntoma: Rendimiento pps de red cae tras refresco de hardware

Causa raíz: IRQs y threads están en diferentes nodos NUMA; el dado de IO y la localidad del NIC importan, y el tráfico entre nodos añade latencia.

Solución: Alinea afinidad de IRQs y threads de aplicación al nodo NUMA del NIC; confirma ancho/velocidad de enlace; evita la sobreconsolidación.

7) Síntoma: “Añadimos caché apilada pero no vimos mejora”

Causa raíz: El conjunto de trabajo no cabe, o la carga está limitada por ancho de banda en lugar de latencia de caché; la ganancia es específica de la carga.

Solución: Perfila tasas de fallos de caché y ancho de banda; prueba tamaños de datos representativos; considera HBM o cambios algorítmicos si estás limitado por ancho de banda.

8) Síntoma: Tras contenerizar, el rendimiento regresó en CPUs chiplet

Causa raíz: El scheduler de contenedores movió hilos entre CPUs/nodos NUMA; las cuotas cgroup CPU introdujeron ráfagas; la localidad del page cache empeoró.

Solución: Usa CPU manager/topology manager, establece requests/limits explícitos adecuadamente y fija pods con uso intensivo de memoria a nodos NUMA.

Listas de verificación / plan paso a paso para nuevas plataformas

Plan paso a paso: llevar una nueva plataforma chiplet/apilada a producción

1. Topología baseline: registra lscpu y numactl --hardware para el SKU; almacénalo con tus artefactos de build.
2. Estandariza firmware: configuraciones BIOS, microcode y políticas de potencia deben ser consistentes en la pool.
3. Elige postura de energía por tier: clusters de latencia obtienen policy performance; clusters batch pueden estar intencionalmente con capado de potencia.
4. Ejecuta pruebas smoke fijadas: mide throughput y p99 con CPU+memoria ligadas a un nodo; luego ejecuta sin fijar; compara deltas.
5. Valida margen de ancho de banda de memoria: si tu carga es limitada por memoria, la planificación de capacidad es planificación de ancho de banda.
6. Valida localidad de E/S: revisa salud de enlaces PCIe y distribución de IRQ; asegura que la afinidad del NIC coincida con la colocación de CPU.
7. Decide política de colocación: acepta NUMA (fijar y localizar) o intercalar explícitamente para ancho de banda. No hagas “híbrido accidental”.
8. Despliega con detección de varianza: vigila no solo medianas sino dispersión entre hosts; alerta temprano sobre “un host raro”.
9. Documenta modos de fallo: firmas de throttling, umbrales de errores corregidos y cómo poner en cuarentena un host.
10. Vuelve a probar tras actualizaciones de kernel: cambios en el scheduler pueden ayudar o perjudicar el manejo de topología; valida periódicamente.

Checklist: decidir entre caché apilada vs más ancho de banda de memoria

• Si tu conjunto de trabajo es ligeramente mayor que el LLC y ves muchos fallos de LLC: la caché apilada puede ser una gran ganancia.
• Si el ancho de banda de memoria está cerca del máximo y los stalls dominan: la caché apilada puede no salvarte; prioriza ancho de banda (plataformas HBM, más canales) o reduce tráfico.
• Si la latencia tail importa: prefiere soluciones que reduzcan la varianza (localidad, política de potencia estable) sobre picos máximos.

Checklist: qué evitar al adoptar CPUs con muchos chiplets

• No asumas “un socket = uniforme.” Mide comportamiento NUMA.
• No aceptes deriva de BIOS en un grupo autoscalado.
• No optimices aplicaciones sin primero verificar comportamiento de potencia y throttling.
• No mezcles cargas de latencia y batch en el mismo socket a menos que tengas aislamiento estricto.

FAQ

1) ¿Los chiplets siempre son más rápidos que los dados monolíticos?

No. Los chiplets son principalmente una estrategia económica y de velocidad de producto, con beneficios de rendimiento cuando la interconexión y la topología están bien gestionadas. La mala localidad puede borrar la ganancia.

2) ¿El apilamiento 3D hará que las CPU funcionen más calientes?

A menudo, sí en la práctica. Las pilas pueden impedir la salida de calor y crear puntos calientes. Los proveedores diseñan alrededor de esto, pero las cargas sostenidas pueden ver throttling más temprano o más varianza.

3) ¿Es obligatorio afinar NUMA ahora?

Para servicios sensibles a latencia en CPUs con muchos chiplets, está casi al borde de ser obligatorio. Para trabajo embarrassingly parallel en batch, a menudo puedes prescindir—hasta que no puedas.

4) ¿Qué cargas se benefician más de caché apilada?

Cargas con un conjunto de trabajo mayor que la caché normal pero más pequeño que patrones de streaming DRAM: workloads clave‑valor calientes, algunas analíticas, ciertas simulaciones y estructuras de datos en memoria con muchas lecturas.

5) ¿Cuál es el riesgo operativo de empaquetado más avanzado?

Más componentes y enlaces pueden significar degradaciones sutiles: tormentas de errores corregidos, downtraining de enlaces o varianza de plataforma. Tus prácticas de monitoreo y cuarentena importan más.

6) ¿Los chiplets significan que “más cores” dejará de ayudar?

Más cores seguirán ayudando para cargas paralelas, pero el escalado será más sensible al ancho de banda de memoria, la congestión de interconexión y la contención de estado compartido. Las ganancias fáciles se acabaron.

7) ¿Cómo cambia HBM la planificación de capacidad?

HBM te empuja hacia un modelo escalonado: ancho de banda muy alto pero capacidad limitada. Planifica qué debe quedarse en HBM, qué puede volcarse a DDR y cómo se comporta tu asignador/runtime.

8) ¿UCIe hará que los paquetes CPU sean modulares como piezas de PC?

Eventualmente, más modulares que hoy—pero no esperes plug‑and‑play. Integridad de señal, suministro de potencia, térmicas y validación siguen siendo difíciles, y el “estándar” no eliminará la física.

9) ¿Cuál es el cambio más simple y “suficientemente bueno” para reducir latencia tail en CPUs chiplet?

Fija tus hilos más calientes a un nodo NUMA y mantén su memoria local. Luego verifica con una prueba A/B fijada. Si ayuda, invierte en scheduling consciente de topología.

10) ¿Debería comprar SKUs con caché apilada para todo?

No. Cómpralas para cargas que demuestren sensibilidad a caché en el profiling. Si no, pagas por silicio que mayormente solo adorna tu hoja de procurement.

Próximos pasos prácticos

El apilamiento 3D y los chiplets no son una tendencia; son la forma del camino por delante. La CPU se está convirtiendo en un sistema distribuido a nivel de paquete con restricciones térmicas y topológicas. Tu software y tu operación deben comportarse en consecuencia.

Qué hacer la próxima semana (no el próximo trimestre)

1. Elige un servicio con SLOs de latencia y ejecuta la prueba NUMA fijada vs no fijada (numactl) para cuantificar sensibilidad.
2. Añade dos paneles a nivel host: frecuencia/throttling de CPU (derivado de turbostat) y accesos remotos NUMA (numastat/derivado de PMU si lo tienes).
3. Estandariza baselines BIOS/microcode para cada pool de hardware; alerta sobre deriva.
4. Escribe un runbook de una página usando el Guion de diagnóstico rápido arriba para que la guardia no culpe a la red por reflejo.
5. Decide tu filosofía de colocación: localidad‑first para tiers de latencia; interleave/ancho‑de‑banda‑first para tiers de throughput—luego aplícalo.

Si no haces nada más, haz esto: deja de tratar el %CPU como la verdad. En chiplets y diseños apilados, %CPU es una vibra. Mide localidad, mide ancho de banda y mide throttling. Entonces podrás discutir con confianza, que es el único tipo de discusión que las operaciones pueden permitirse.

Guía rápida de diagnóstico

Si estás de guardia y el cluster está gritando, no quieres una clase de filosofía. Quieres un bucle cerrado:
confirma el modo de fallo, identifica el limitador, haz un cambio seguro, repite.

Primero: ¿es esto agotamiento de memoria del host o un límite por VM?

• Si la VM falla al iniciar con no se puede asignar memoria, sospecha límites de compromiso del host,
  límites de cgroup, hugepages o fragmentación—a menudo visible inmediatamente en dmesg / journal.
• Si la VM arranca y luego es asesinada, suele ser el OOM killer del invitado (dentro de la VM) o
  el OOM killer del host (matando QEMU), dependiendo de qué registros muestren el golpe.

Segundo: comprueba la «capacidad real» del host, no los gráficos bonitos

• Memoria libre del host y swap: free -h
• Presión de memoria del host y stalls de reclaim: vmstat 1
• Evidencia de OOM: journalctl -k y dmesg -T
• Tamaño de ZFS ARC (si usas ZFS): arcstat / /proc/spl/kstat/zfs/arcstats

Tercero: verifica la asignación y la política en el lado de Proxmox

• Configuración de la VM: objetivo de ballooning vs máximo, hugepages, NUMA, etc.:
  qm config <vmid>
• Política de sobreasignación del nodo: pvesh get /nodes/<node>/status y
  /etc/pve/datacenter.cfg
• Si es un contenedor (LXC), comprueba el límite de memoria del cgroup y el límite de swap:
  pct config <ctid>

Cuarto: elige la mitigación inmediata menos mala

• Para liberar RAM y reducir la presión ahora: detén una VM no crítica.
• Si ZFS está comiéndose la máquina: limita ARC (persistente) o reinicia como último recurso.
• Si estás sobreasignado: reduce la memoria máxima de las VMs (no solo el objetivo del balloon).
• Si no hay swap y estás justo: añade swap (host) para evitar OOM instantáneos mientras arreglas el dimensionamiento.

Chiste #1: La sobreasignación de memoria es como el presupuesto corporativo—todo funciona hasta que todos tratan de justificar el almuerzo el mismo día.

Qué significa realmente «no se puede asignar memoria» en Proxmox

Proxmox es una capa de gestión. El asignador real es Linux, y para VMs suele ser QEMU/KVM. Cuando ves
no se puede asignar memoria, está ocurriendo una de estas cosas:

• QEMU no puede reservar la RAM solicitada por la VM en el momento de inicio. Eso puede fallar incluso si
  free parece correcto, porque a Linux le importan las reglas de compromiso y la fragmentación.
• El kernel rechaza la asignación debido a la lógica de overcommit/CommitLimit. Linux rastrea cuánto
  memoria han prometido potencialmente usar los procesos (memoria virtual), y puede negar nuevas promesas.
• Se piden hugepages pero no están disponibles. Las hugepages están pre-reservadas. Si no existen,
  la asignación falla de forma inmediata y ruidosa.
• Los límites de cgroup bloquean la asignación. Más común con contenedores, pero puede aplicarse si systemd
  slices o cgroups personalizados están en juego.
• La memoria está disponible pero no en la forma que pediste. La fragmentación puede impedir asignaciones
  contiguas grandes, especialmente con hugepages o ciertas necesidades DMA.

Mientras tanto, la «solución» a la que recurren la gente—ballooning—no cambia lo que QEMU pidió si aún configuraste una gran
memoria máxima. Ballooning ajusta lo que el invitado se anima a usar, no lo que el host debe estar preparado
para respaldar en el peor momento posible.

Dos números importan: objetivo del invitado y máximo del invitado

En las opciones de VM de Proxmox, el ballooning te da:

• Memory (max): el techo de la VM. QEMU contabiliza reservas por ello.
• Balloon (min/target): el objetivo en tiempo de ejecución que puede reducirse bajo presión.

Si estableces max en 64 GB «por si acaso» y objetivo del balloon en 8 GB «porque normalmente está inactiva», le has dicho al host:
«Por favor, prepárate para cubrir mis 64 GB de estilo de vida». El host, siendo adulto, puede decir que no.

Hechos interesantes y un poco de historia (para que no lo repitas)

1. El comportamiento de overcommit de Linux es antiguo e intencional: existe porque muchas asignaciones nunca se usan por completo,
   y una contabilidad estricta desperdiciaría RAM en promesas vacías.
2. El OOM killer precede a la mayoría de las pilas modernas de virtualización; fue la respuesta pragmática de Linux a «alguien está mintiendo
   sobre la memoria» mucho antes de que el marketing de la nube convirtiera mentir en una característica.
3. El ballooning se volvió común con los primeros hipervisores porque los invitados ociosos acaparaban caché y hacían que la consolidación
   pareciera peor de lo que era.
4. KSM (Kernel Samepage Merging) fue diseñado para desduplicar páginas de memoria idénticas entre VMs—especialmente común cuando
   muchas VMs ejecutan la misma imagen del SO.
5. Transparent Huge Pages (THP) se introdujeron para mejorar el rendimiento usando páginas mayores automáticamente, pero
   pueden crear picos de latencia bajo presión de memoria debido al trabajo de compactación.
6. ZFS ARC no es «solo caché». Compite con la memoria anónima. Si no lo limitas, consumirá RAM hasta que el kernel lo obligue
   a ceder—a veces demasiado tarde.
7. Los cgroups cambiaron la situación: en lugar de que todo el host sea una familia feliz, ahora los límites de memoria pueden
   hacer que una sola VM o contenedor falle aun cuando el host parece bien.
8. Antes se recomendaba swap obligatoriamente; luego la gente lo abusó; luego la gente lo rechazó; luego los SSD modernos hicieron
   que «un swap pequeño y controlado» vuelva a tener sentido en muchos casos.

Una cita operativa que sigue siendo dolorosamente relevante (idea parafraseada): Werner Vogels ha dicho que el núcleo de la
fiabilidad es esperar fallos y diseñar para ello, no fingir que no ocurrirán.

Ballooning: qué hace, qué no hace y por qué te confunde

Qué es realmente el ballooning

El ballooning usa un driver dentro del invitado (típicamente virtio-balloon). El host le pide al invitado «inflar» un globo,
es decir: asignar memoria dentro del invitado y fijarla para que el invitado no pueda usarla. Desde la perspectiva del host,
esa memoria pasa a ser reclamable porque el invitado la cedió voluntariamente.

Es ingenioso. También está limitado por la física y el comportamiento del invitado:

• Si el invitado está bajo presión real de memoria, no puede darte mucho sin hacer swap o sufrir OOM él mismo.
• Si el invitado no tiene el driver del balloon, el ballooning es básicamente danza interpretativa.
• El ballooning es reactivo. Si el host ya está en problemas, puede que llegues demasiado tarde.

Ballooning en Proxmox: la trampa importante

La configuración de ballooning en Proxmox a menudo da una falsa sensación de seguridad. La gente pone objetivos de balloon bajos y
memoria máxima alta, pensando que «solo usan el objetivo». Pero la contabilidad de QEMU y la lógica de compromiso del kernel
a menudo deben considerar la máxima.

Postura operativa: el ballooning es una herramienta de ajuste, no una excusa para evitar dimensionar. Úsalo para
cargas elásticas donde el SO invitado pueda manejarlo. No lo uses como estrategia principal para meter VMs en un host hasta que
este se queje.

Cuándo vale la pena el ballooning

• Clusters de desarrollo/pruebas donde los invitados están inactivos y los picos son raros y tolerables.
• Flotas tipo VDI con muchas VMs similares, a menudo combinadas con KSM.
• Servidores de propósito general donde puedes imponer valores máximos sensatos, no fantasiosos.

Cuándo el ballooning es una trampa

• Bases de datos con latencia estricta y pools de búfer (la presión de memoria en el invitado se convierte en presión IO).
• Sistemas con swap deshabilitado en los invitados (el ballooning puede forzar OOM dentro del invitado).
• Hosts ya ajustados en memoria donde el tiempo de respuesta del ballooning es demasiado lento.

Sobreasignación: cuándo es sensata y cuándo es temeraria

Tres «sobreasignaciones» diferentes que la gente confunde

En la práctica, estás manejando tres capas:

1. Sobreasignación del scheduler/contabilidad de Proxmox: si Proxmox cree que está bien iniciar otra VM
   según la RAM configurada, objetivos de balloon y la memoria del nodo.
2. Sobreasignación de memoria virtual de Linux: vm.overcommit_memory y CommitLimit.
3. Sobreasignación física real: si la suma de la memoria activamente usada por los invitados excede la RAM del host
   (y si tienes swap, compresión o un plan).

Contabilidad de commit de Linux en un párrafo operativo

Linux decide si permitir una asignación basada en cuánto podría usarse si los procesos lo tocan. Ese número «podría usarse» se
rastrea como Committed_AS. El techo permitido es CommitLimit, aproximadamente RAM + swap menos algunas reservas,
modificado por las configuraciones de overcommit. Si Committed_AS se acerca al CommitLimit, el kernel empieza
a rechazar asignaciones—hola, «no se puede asignar memoria».

Guía con opinión

• Producción: mantén la sobreasignación moderada y aplica máximos de VM realistas. Si no puedes declarar tu
  ratio de sobreasignación y tu plan de expulsión, no estás sobreasignando—estás apostando.
• Laboratorio: sobreasigna agresivamente si aceptas eventos OOM ocasionales. Solo etiquétalo honestamente y deja de fingir que es prod.
• Cargas mixtas: separa usuarios ruidosos de memoria (BD, analítica) en sus propios nodos o capéalos fuertemente.
  «Coexistencia» es como la gente llama a la situación justo antes de la revisión del incidente.

ZFS ARC, caché de páginas y la memoria del host que olvidaste presupuestar

Proxmox a menudo se ejecuta sobre ZFS porque los snapshots y send/receive son adictivos. Pero ZFS no tiene vergüenza: usará RAM
para ARC (Adaptive Replacement Cache). Eso es genial hasta que no lo es.

ARC frente a «memoria libre»

ARC es reclamable, pero no instantáneamente y no siempre de la forma que quiere el inicio de una VM. Bajo presión, el kernel
intenta reclamar page cache y ARC, pero si estás en un bucle ajustado de asignaciones (iniciar una VM, inflar memoria,
forkear procesos), puedes sufrir fallos transitorios.

Qué hacer

• En hosts ZFS con muchas VMs, fija un máximo sensato para ARC (zfs_arc_max). No dejes que ARC «compita» con tus invitados.
• Trata la memoria del host como infraestructura compartida. El host necesita memoria para:
  kernel, slab, red, metadatos ZFS, overhead de QEMU y tus agentes de monitorización que juran ser ligeros.

Swap: no es un pecado, pero tampoco un plan de vida

No tener swap significa que has quitado los amortiguadores. Con virtualización, eso puede ser fatal porque un pico repentino
de presión se convierte en kills OOM inmediatos en lugar de una degradación lenta y diagnosticable.

Pero el swap también puede convertirse en un lodazal de rendimiento. El objetivo es un swap controlado: suficiente para
sobrevivir a ráfagas, no suficiente para ocultar una sobreasignación crónica.

Recomendaciones de swap para el host (prácticas, no dogmáticas)

• Si ejecutas ZFS y muchas VMs: añade swap. Incluso una cantidad moderada puede evitar que el host mate
  QEMU durante picos breves.
• Si tu almacenamiento es lento: mantén el swap más pequeño y prioriza un dimensionamiento correcto de RAM.
  Hacer swap a un RAID HDD ocupado no es «estabilidad», es «sufrimiento prolongado».
• Si usas SSD/NVMe: el swap es mucho más tolerable, pero sigue sin ser gratuito. Monitoriza la tasa de swap-in/out,
  no solo el swap usado.

Chiste #2: El swap es como una reunión que pudo haber sido un correo—a veces salva el día, pero si vives allí, tu carrera se acaba.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las comprobaciones que realmente ejecuto cuando un nodo Proxmox empieza a lanzar errores de asignación de memoria. Cada tarea incluye:
un comando, salida de ejemplo, qué significa y qué decisión impulsa.

Tarea 1: Comprobar RAM y swap del host de un vistazo

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        54Gi       1.2Gi       2.3Gi       6.9Gi       2.8Gi
Swap:            8Gi       1.6Gi       6.4Gi

Significado: «available» es tu margen a corto plazo antes de que el reclaim se ponga feo. 2.8 GiB en un host de 62 GiB
con virtualización es ajustado pero no instantáneamente catastrófico.

Decisión: Si available es < 1–2 GiB y las VMs están fallando al iniciar, detén VMs no críticas ahora.
Si swap es 0, añade swap como estabilizador mientras corriges el dimensionado.

Tarea 2: Identificar si el kernel está rechazando asignaciones por límites de commit

cr0x@server:~$ grep -E 'CommitLimit|Committed_AS' /proc/meminfo
CommitLimit:    71303168 kB
Committed_AS:   70598240 kB

Significado: Estás cerca del techo de commit. El kernel puede rechazar nuevas reservas de memoria incluso si
hay caché que podría reclamarse.

Decisión: Reduce las memorias máximas de las VMs, añade swap (aumenta CommitLimit) o mueve cargas.
Cambios en el objetivo del balloon no ayudarán si el problema es el máximo.

Tarea 3: Confirmar la política de sobreasignación

cr0x@server:~$ sysctl vm.overcommit_memory vm.overcommit_ratio
vm.overcommit_memory = 0
vm.overcommit_ratio = 50

Significado: El modo 0 es overcommit heurístico. Ratio importa sobre todo para el modo 2. Aún así, la conducta de commit está en juego.

Decisión: No cambies esto en pánico a menos que entiendas el impacto. Si estás tocando los límites de commit,
arreglar el dimensionado es mejor que «simplemente sobreasignar más».

Tarea 4: Buscar evidencia del OOM killer en el host

cr0x@server:~$ journalctl -k -b | tail -n 30
Dec 26 10:14:03 pve1 kernel: Out of memory: Killed process 21433 (qemu-system-x86) total-vm:28751400kB, anon-rss:23110248kB, file-rss:0kB, shmem-rss:0kB
Dec 26 10:14:03 pve1 kernel: oom_reaper: reaped process 21433 (qemu-system-x86), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Significado: El host mató a QEMU. Esa VM no «falló», fue ejecutada.

Decisión: Trátalo como agotamiento de memoria del host/sobreasignación. Reduce consolidación, capea ARC, añade swap
y deja de confiar en el ballooning como cinturón de seguridad.

Tarea 5: Comprobar la presión de memoria y el comportamiento de reclaim en vivo

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
 6  1 1677720 312000  8200 5120000  40  120   180   260  900 1800 18 12 55 15  0
 5  2 1677800 280000  8100 5010000  10  200   140   320  920 1700 15 10 50 25  0
 7  3 1677850 260000  8000 4920000  80  500   220   600 1100 2200 20 15 35 30  0

Significado: Valores no nulos en si/so indican swapping. Alto wa sugiere IO wait.
Si b crece y id se desploma, el host está thrashing.

Decisión: Si el swapping es sostenido y el IO wait sube, detén VMs o mueve carga. No puedes «afinar» para salir de una tormenta de thrash en tiempo real.

Tarea 6: Encontrar los mayores consumidores de memoria en el host (RSS, no fantasías VIRT)

cr0x@server:~$ ps -eo pid,comm,rss,vsz --sort=-rss | head -n 10
 21433 qemu-system-x86 23110248 28751400
 19877 qemu-system-x86 16188012 21045740
  1652 pveproxy          312400  824000
  1321 pvedaemon         210880  693000
  1799 zfs               180200  0
  1544 pvestatd          122000  610000

Significado: RSS es memoria residente real. Los procesos QEMU dominan, como era de esperar.

Decisión: Si una VM se descontrola, capea su memoria máxima o investiga dentro del invitado.
Si son «muchas VMs medianas», es matemática de consolidación, no un villano único.

Tarea 7: Inspeccionar la configuración de memoria de una VM (ballooning vs max)

cr0x@server:~$ qm config 104 | egrep 'memory|balloon|numa|hugepages'
memory: 32768
balloon: 8192
numa: 1
hugepages: 2

Significado: Max es 32 GiB, objetivo del balloon 8 GiB. Hugepages están habilitadas (2 = hugepages de 2MB).

Decisión: Si el nodo falla al asignar, el max de 32 GiB de esta VM podría ser demasiado generoso.
Si hugepages están habilitadas, confirma disponibilidad de hugepages (Tarea 8) o deshabilítalas para más flexibilidad.

Tarea 8: Validar disponibilidad de hugepages (causa clásica de fallos al iniciar)

cr0x@server:~$ grep -i huge /proc/meminfo
AnonHugePages:   1048576 kB
HugePages_Total:    8192
HugePages_Free:      120
HugePages_Rsvd:       50
Hugepagesize:       2048 kB

Significado: Solo 120 hugepages libres (~240 MiB). Si intentas iniciar una VM que necesita muchas hugepages, falla.

Decisión: O provisiona suficientes hugepages en el arranque, o deja de usar hugepages para esa clase de VMs.
Las hugepages son una herramienta de rendimiento, no un defecto por defecto.

Tarea 9: Comprobar el comportamiento de THP (puede causar latencia bajo presión)

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

Significado: THP está habilitado siempre.

Decisión: Para nodos sensibles a la latencia, considera madvise o never.
No cambies esto en medio de un incidente a menos que estés seguro; planea un mantenimiento y mide.

Tarea 10: Si usas ZFS, verifica rápidamente el tamaño del ARC

cr0x@server:~$ awk '/^size/ {print}' /proc/spl/kstat/zfs/arcstats
size                            4    34359738368

Significado: ARC es ~32 GiB. En un host de 64 GiB con muchas VMs, eso puede ser demasiado.

Decisión: Si te falta memoria y ARC es grande, limita ARC de forma persistente (ver sección de checklist)
y planifica un reinicio si necesitas alivio inmediato.

Tarea 11: Confirmar estado de KSM (ayuda con muchas VMs similares, pero puede costar CPU)

cr0x@server:~$ systemctl is-active ksmtuned
inactive

Significado: El servicio de tuning de KSM no está activo. En algunas configuraciones Proxmox, KSM se configura diferente;
esto es solo una señal rápida.

Decisión: Si ejecutas docenas de VMs similares, habilitar KSM puede reducir uso de memoria. Si la CPU ya está caliente,
KSM puede ser contraproducente. Prueba en un nodo primero.

Tarea 12: Comprobar info de memoria en el nodo Proxmox (qué cree Proxmox que está pasando)

cr0x@server:~$ pvesh get /nodes/pve1/status | egrep '"memory"|"swap"|"loadavg"'
"loadavg": [
  "2.61",
  "2.45",
  "2.31"
],
"memory": {
  "free": 1288490188,
  "total": 66571993088,
  "used": 651834
},
"swap": {
  "free": 6871947673,
  "total": 8589934592,
  "used": 1717986919
}

Significado: La API de Proxmox da una vista que puede diferir de tus expectativas inmediatas (unidades,
caching y tiempo). No la trates como verdad absoluta; coteja con free y meminfo.

Decisión: Usa esto para automatización y dashboards, pero al depurar fallos de asignación, confía primero
en la evidencia del kernel y los logs de QEMU.

Tarea 13: Inspeccionar un fallo de inicio de VM en los logs de tareas

cr0x@server:~$ journalctl -u pvedaemon -b | tail -n 20
Dec 26 10:18:11 pve1 pvedaemon[1321]: start VM 104: UPID:pve1:0000A3F9:00B2B6D1:676D5A13:qmstart:104:root@pam:
Dec 26 10:18:12 pve1 pvedaemon[1321]: VM 104 qmp command failed - unable to execute QMP command 'cont': Cannot allocate memory
Dec 26 10:18:12 pve1 pvedaemon[1321]: start failed: command '/usr/bin/kvm -id 104 ...' failed: exit code 1

Significado: El fallo está en la etapa de arranque/cont de QEMU, no dentro del invitado.

Decisión: Concéntrate en límites de commit del host, hugepages y fragmentación—no en ajustes dentro del invitado.

Tarea 14: Validar la configuración de memoria de un contenedor (LXC) y el límite de swap

cr0x@server:~$ pct config 210 | egrep 'memory|swap|features'
memory: 4096
swap: 512
features: nesting=1,keyctl=1

Significado: El contenedor tiene 4 GiB RAM y 512 MiB de swap permitido. Si hace picos por encima, las asignaciones fallan dentro del contenedor.

Decisión: Para contenedores, «no se puede asignar memoria» suele ser un límite de cgroup. Aumenta memory/swap
o arregla el comportamiento de la aplicación. La memoria libre del host no salvará a un LXC con un techo rígido.

Tarea 15: Comprobar señales de riesgo de fragmentación (rápido y tocho)

cr0x@server:~$ cat /proc/buddyinfo | head
Node 0, zone      DMA      1      1      1      1      0      0      0      0      0      0      0
Node 0, zone    DMA32   1024    512    220     12      0      0      0      0      0      0      0
Node 0, zone   Normal   2048   1880    940    110      2      0      0      0      0      0      0

Significado: El buddy allocator muestra cuántos bloques libres existen en diferentes órdenes. Si los órdenes altos están
mayormente en cero, las asignaciones contiguas grandes (incluyendo algunas necesidades de hugepage) pueden fallar aun con «suficiente total libre».

Decisión: Si las hugepages/THP/compactación son parte de tu configuración, considera reducir la dependencia de asignaciones
contiguas o programar reinicios de mantenimiento periódicos para nodos que deben satisfacer esas asignaciones.

Tres microhistorias corporativas desde el frente

Incidente: una suposición errónea («ballooning significa que no reservará el máximo»)

Una compañía mediana ejecutaba un cluster Proxmox interno para apps de línea de negocio y algunos trabajos batch pesados.
El equipo tenía la costumbre: poner la memoria máxima de la VM alta «para que nadie tenga que abrir un ticket», y luego poner
el objetivo del balloon bajo para «mantener la utilización eficiente».

Funcionó—hasta que actualizaron algunas VMs y lanzaron una corrida de reportes trimestrales. Nuevos procesos se generaron, los mapas de memoria
se expandieron y varias VMs se reiniciaron para parcheo. De repente: no se puede asignar memoria al iniciar VMs.
El dashboard aún mostraba «free» porque la caché parecía reclamable.

La causa raíz no fue una fuga. Fue contabilidad. El Committed_AS del host se acercó al CommitLimit.
Cada VM con un máximo generoso contribuyó al total de memoria prometida, aunque «normalmente» estuviera baja. Cuando varios
reinicios ocurrieron juntos, QEMU intentó reservar lo que se le había dicho que podía necesitar. El kernel se negó. El error
fue correcto; su modelo mental no.

La solución fue aburrida: redujeron la memoria máxima de las VMs a lo que cada servicio podía justificar, mantuvieron el ballooning
para elasticidad y añadieron swap en hosts donde faltaba. Lo más importante: dejaron de tratar el «max» como un deseo.
La siguiente corrida trimestral aún hizo picos, pero dejó de romper los reinicios.

Optimización que salió mal (hugepages por todas partes)

Otra organización persiguió la latencia. Un ingeniero orientado al rendimiento habilitó hugepages para toda una clase de VMs porque un blog
decía que mejoraba el comportamiento del TLB. Y puede hacerlo. También dejaron Transparent Huge Pages en «always», porque más hugepages
sonaban a más rendimiento. Así es como el optimismo se vuelve configuración.

Durante semanas, todo parecía bien. Luego un nodo empezó a fallar al iniciar VMs tras migraciones rutinarias. La misma VM arrancaba en
otros nodos. En este nodo: no se puede asignar memoria. La memoria libre no estaba mal, pero las hugepages libres estaban casi a cero.
Buddyinfo mostró fragmentación: la memoria existía, solo que no en los trozos adecuados.

Intentaron «arreglarlo» aumentando hugepages dinámicamente. Eso lo empeoró: el kernel tuvo que compactar memoria para satisfacer la petición,
generando picos de CPU y bloqueando reclaim. La latencia se disparó durante las horas punta. Lo mejor es que el informe de incidente lo llamó
«intermitente». Fue intermitente como la gravedad lo es cuando estás dentro de una habitación.

El plan de recuperación fue: deshabilitar hugepages para VMs generales, reservar hugepages solo para un pequeño conjunto de instancias
críticas y previsibles, y poner THP en madvise. El rendimiento mejoró en general porque el sistema dejó de pelear consigo mismo.

Práctica aburrida pero correcta que salvó el día (reserva y límites en el host)

Un tercer equipo usaba Proxmox para cargas mixtas: apps web, algunas VMs Windows y un par de appliances intensivos en almacenamiento.
Tenían una regla sosa: cada nodo mantiene una «reserva del host» fija de RAM que nunca se asigna a invitados en papel.
También limitaron ZFS ARC desde el primer día.

No era sofisticado. Significaba que podían ejecutar menos VMs por nodo de lo que la hoja de cálculo quería. Pero durante un incidente
donde un invitado ruidoso empezó a consumir memoria (un servicio Java mal configurado), el host tuvo suficiente margen para mantener
vivos los procesos QEMU y evitar un OOM del host.

El invitado aún sufrió (como debía), pero el radio de impacto se quedó dentro de esa VM. El cluster no empezó a matar cargas no relacionadas.
Dranearon el nodo, arreglaron la configuración del invitado y reanudaron. Sin reinicio a medianoche, sin fallos en cascada, sin «¿por qué murió nuestra VM de firewall?»

La práctica que los salvó no fue un ajuste secreto del kernel. Fue presupuestar y negarse a gastar el fondo de emergencia.

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

La VM no arranca: «No se puede asignar memoria» inmediatamente

• Síntoma: El inicio falla al instante; QEMU sale con error de asignación.
• Causa raíz: Límite de commit del host alcanzado, hugepages faltantes o fragmentación para la asignación solicitada.
• Solución: Baja la memoria máxima de la VM; añade swap en el host; deshabilita hugepages para esa VM; provisiona hugepages en el arranque si es necesario.

La VM arranca y luego se apaga o reinicia aleatoriamente

• Síntoma: La VM parece «caerse», los logs no muestran un apagado limpio.
• Causa raíz: El OOM killer del host mató a QEMU, a menudo tras un pico de memoria o un reclaim intenso.
• Solución: Encuentra logs de OOM; reduce la sobreasignación del host; reserva memoria del host; capea ZFS ARC; asegúrate de que exista swap y monitoriza su actividad.

Los invitados se vuelven lentos, luego el host se vuelve lento y todo se vuelve filosófico

• Síntoma: IO wait sube; tasas de swap-in/out aumentan; la latencia de las VMs se dispara.
• Causa raíz: Thrashing: no hay suficiente RAM para los working sets, y swap/reclaim domina.
• Solución: Detén o migra VMs; reduce límites de memoria; añade RAM; rediseña la consolidación. Ningún sysctl te salvará aquí.

Ballooning habilitado pero la memoria nunca «vuelve»

• Síntoma: El host sigue lleno; los invitados no liberan memoria como se esperaba.
• Causa raíz: Driver de balloon no instalado/activo, el invitado no puede reclamar o el «max» aún obliga al compromiso del host.
• Solución: Instala el driver virtio-balloon; verifica dentro del invitado; fija un max realista; usa ballooning como elasticidad, no como sustituto del dimensionado.

Todo iba bien hasta que aumentaron los snapshots y la replicación de ZFS

• Síntoma: La presión de memoria del host aumenta durante actividad intensiva de almacenamiento; se fallan inicios de VM.
• Causa raíz: Crecimiento del ARC, presión de metadatos, crecimiento de slab y uso de memoria dependiente de IO.
• Solución: Capa ARC; monitoriza slab; mantén margen; evita correr el nodo al 95% de «usado» y llamarlo eficiente.

Los contenedores muestran «no se puede asignar memoria» mientras el host tiene bastante

• Síntoma: Apps dentro de LXC fallan asignaciones; el host parece bien.
• Causa raíz: Límite de memoria del cgroup alcanzado (cupo memory/swap del contenedor).
• Solución: Eleva límites del contenedor; ajusta la aplicación; asegúrate de que el swap del contenedor esté permitido si esperas picos.

Listas de comprobación / plan paso a paso

Paso a paso: arreglar un nodo que lanza errores de asignación

1. Confirma OOM del host vs fallo en tiempo de inicio.
   Revisa journalctl -k por kills OOM y logs de pvedaemon para el contexto del fallo de inicio.
2. Mide la presión de commit.
   Si Committed_AS está cerca de CommitLimit, estás en territorio de «promesas exceden la realidad».
3. Lista VMs con memoria máxima grande.
   Reduce la memoria máxima de las culpables. No te limites a ajustar objetivos de balloon.
4. Comprueba hugepages y ajustes de THP.
   Si hugepages están habilitadas para VMs, asegúrate de preasignación adecuada o apágalas para cargas generales.
5. Comprueba ZFS ARC si aplica.
   Si ARC es grande y eres primero un host de VMs, capéalo.
6. Asegúrate de que exista swap y sea sensato.
   Añade swap si no hay; monitoriza si/so. El swap es para picos, no para pagar la renta.
7. Reserva memoria para el host.
   Mantén un buffer fijo para host + ZFS + overhead de QEMU. Tu yo futuro te lo agradecerá en silencio.
8. Vuelve a probar inicios de VM en secuencia controlada.
   No inicies todo de golpe tras ajustar. Inicia servicios críticos primero.

Ajuste persistente: tope de ZFS ARC (ejemplo)

Si el nodo es un host de VMs y ZFS es un medio, establece un máximo para ARC. Un método común:
crea un archivo de configuración de modprobe y actualiza initramfs para que se aplique al arranque.

cr0x@server:~$ echo "options zfs zfs_arc_max=17179869184" | sudo tee /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=17179869184
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.12-4-pve

Significado: ARC capado a 16 GiB (el valor está en bytes). Le acabas de decir a ZFS que no se coma toda la máquina.

Decisión: Elige un tope que deje suficiente RAM para invitados más la reserva del host. Valida tras reiniciar leyendo arcstats de nuevo.

Ajuste persistente: añadir swap al host (ejemplo con archivo)

cr0x@server:~$ sudo fallocate -l 8G /swapfile
cr0x@server:~$ sudo chmod 600 /swapfile
cr0x@server:~$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=0a3b1e4c-2f1e-4f65-a3da-b8c6e3f3a8d7
cr0x@server:~$ sudo swapon /swapfile
cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file   8G   0B   -2

Significado: El swap está activo. CommitLimit aumenta y tienes un colchón contra ráfagas de asignación.

Decisión: Si el uso de swap se vuelve sostenido con alto si/so, eso no está «funcionando como diseñado».
Es señal de reducir consolidación o añadir RAM.

Política: reservar RAM para el host (una regla simple que funciona)

• Reserva al menos 10–20% de la RAM del host para el host en nodos mixtos.
  Más si ejecutas ZFS, Ceph, redes pesadas o muchas VMs pequeñas.
• Mantén un objetivo de «suma máxima de memoria de invitados» que puedas defender. Si la suma de los valores máximos de VM excede un múltiplo fijo
  de la RAM del host, hazlo intencionalmente y solo donde el comportamiento de cargas lo soporte.

Checklist de ballooning (úsalo correctamente)

Preguntas frecuentes

1) ¿Por qué Proxmox dice «no se puede asignar memoria» cuando free muestra GB libres?

Porque free muestra una instantánea de la memoria física, mientras que la contabilidad de commit del kernel y las reglas de fragmentación
pueden negar una nueva asignación. Además, «free» ignora si la memoria está disponible en la forma necesaria (p. ej., hugepages).

2) ¿El ballooning reduce lo que el host debe reservar?

Reduce lo que el invitado usa en tiempo de ejecución, pero si tu VM tiene un máximo alto, el host todavía puede estar obligado por la promesa.
Ballooning no es un salvoconducto para evitar dimensionar.

3) ¿Debería poner vm.overcommit_memory=1 para evitar fallos de asignación?

Eso es una herramienta brusca. Puede reducir fallos en el inicio, pero aumenta la posibilidad de un OOM catastrófico después.
En producción, es preferible arreglar el dimensionado de VMs y añadir swap antes que aflojar las barreras de seguridad del kernel.

4) ¿Cuánto swap debería tener un host Proxmox?

Suficiente para sobrevivir ráfagas y mejorar CommitLimit, no tanto como para ocultar una sobreasignación crónica. Comúnmente: unos pocos GB hasta decenas bajas de GB
dependiendo de la RAM del host y la volatilidad de las cargas. Mide la actividad de swap; si está constantemente ocupada, estás subdimensionado.

5) ¿Es ZFS ARC la razón por la que mi nodo «se queda sin memoria»?

A veces. ARC puede crecer y competir con las VMs. Si los inicios de VM fallan o el host OOM mientras ARC es masivo,
limita ARC. Si ARC es moderado, busca en otro lado (límites de commit, hugepages, invitados descontrolados).

6) ¿Debería habilitar KSM en Proxmox?

Si ejecutas muchas VMs similares (mismo SO, páginas de memoria parecidas), KSM puede ahorrar RAM. Cuesta CPU y puede añadir latencia.
Habilítalo deliberadamente, mide la sobrecarga de CPU y no lo trates como memoria gratis.

7) ¿Por qué los contenedores reciben «no se puede asignar memoria» cuando el host está bien?

LXC está gobernado por cgroups. Un contenedor puede quedarse sin memoria dentro de su límite aunque el host tenga bastante.
Ajusta límites con pct o arregla la carga del contenedor.

8) ¿Merecen la pena las hugepages?

Para ciertas cargas de alto rendimiento y baja latencia: sí. Para consolidación general: a menudo no.
Las hugepages aumentan la predictibilidad del comportamiento del TLB pero reducen la flexibilidad y pueden crear fallos de inicio si no se provisioning con cuidado.

9) ¿Cuál es la diferencia entre OOM del invitado y OOM del host?

OOM del invitado ocurre dentro de la VM: el kernel del invitado mata procesos, pero la VM sigue en pie. OOM del host mata procesos en
el hipervisor, incluyendo QEMU—tu VM desaparece. El OOM del host es el que arruina la tarde.

10) ¿Puedo «arreglar» esto permanentemente sin añadir RAM?

A menudo sí: fija memorias máximas realistas para las VMs, reserva RAM para el host, limita ARC si hace falta y evita ratios de sobreasignación
que asumen milagros. Si los working sets exceden genuinamente la RAM física, la solución permanente es: más RAM o menos cargas por nodo.

Próximos pasos (los sensatos)

«No se puede asignar memoria» en Proxmox no es una maldición. Es el kernel aplicando un límite que ya cruzaste en
política, configuración o expectativas.

1. Deja de tratar la memoria máxima de la VM como sugerencia. Hazla un contrato.
2. Usa ballooning para elasticidad, no para negación. Objetivo bajo, tope realista.
3. Da al host un fondo de emergencia. Reserva RAM; añade swap; mantén ZFS ARC en su carril.
4. Prefiere nodos predecibles sobre ajustes heroicos. Separa cargas cuando sus modos de fallo difieran.
5. Operationaliza esto. Añade alertas para proximidad a CommitLimit, tasa de swap-in/out, logs OOM y tamaño de ARC.

Haz eso, y la próxima vez que Proxmox se queje de memoria, será porque realmente te quedaste sin ella—no porque tu
configuración contó una historia encantadora que el kernel se negó a creer.

La tesis: GHz era un proxy, no un producto

NetBurst se diseñó para frecuencia. No “frecuencia eficiente” ni “buena frecuencia”, sino “pon el número en la caja
y que el mundo lo discuta después”. Intel había pasado años entrenando a los clientes a interpretar la velocidad de reloj
como rendimiento. El mercado recompensó esa simplificación. Luego llegaron las facturas: pipelines de instrucciones tan largos
que las predicciones fallidas eran costosas, un subsistema de memoria que no podía seguir el ritmo y una densidad de potencia que convirtió
el diseño de rack en un pasatiempo para los nerds de HVAC.

Esto no fue una sola mala decisión de diseño. Fue un conjunto apilado de compensaciones que todas asumían una cosa:
los relojes seguirían subiendo y el software jugaría junto. Cuando cualquiera de esas suposiciones falló—código con muchas ramas, cargas pesadas en memoria,
restricciones realistas del datacenter—todo el enfoque se desplomó.

Si quieres la traducción SRE: NetBurst se optimizó para picos bajo microbenchmarks ideales y castigó la latencia de cola
bajo carga mixta de producción. Se puede enviar mucha decepción así.

Exactamente una vez vi una presentación de compras tratar “3.0 GHz” como si fuera un SLA de throughput.
Eso es como estimar el rendimiento de red contando las letras en “Ethernet”.

Internos de NetBurst: la tubería que se comió tu IPC

Canalizaciones profundas: geniales para frecuencia, terribles para errores

La historia clásica de NetBurst es “pipeline muy profundo”. La historia práctica es “alto coste por predicción fallida”.
Un pipeline más profundo te ayuda a alcanzar frecuencias más altas porque cada etapa hace menos trabajo. La desventaja es que ahora
has alargado la distancia entre “creímos la rama” y “descubrimos que estábamos equivocados”. Cuando estás equivocado, limpias mucho trabajo en vuelo y empiezas de nuevo.

Las CPUs modernas siguen teniendo pipelines profundos, pero lo compensan con predictores mejores, cachés más grandes, ejecución más ancha
y gestión de potencia cuidadosa. NetBurst se metió profundo temprano, con predictores y sistemas de memoria que no cubrían completamente
la apuesta en rutas de código típicas de servidor.

Trace cache: ingenioso, complejo y sensible a la carga

La trace cache de NetBurst almacenaba micro-ops (uops) decodificados, no instrucciones x86 crudas. Era inteligente: decodificar x86
no es trivial, y una uop cache puede reducir el coste del front-end. Pero también hizo el rendimiento más dependiente de cómo fluía y se alineaba el código.
Si tu flujo de instrucciones no encajaba bien—muchas ramas, distribución extraña, mala localidad—la trace cache dejó de ser un regalo y se convirtió en otro lugar donde fallar.

La idea no estaba mal; era temprana y frágil. Las uop caches de hoy funcionan porque el resto del sistema mejoró al alimentarlas, y porque
los trade-offs de potencia/rendimiento se gestionan con más delicadeza.

FSB y northbridge compartido: la caseta de peaje del ancho de banda

Los sistemas Pentium 4 dependían de un front-side bus (FSB) hacia un controlador de memoria separado (northbridge). Eso significa que tu
núcleo CPU es rápido, tu memoria está “en otro lugar” y cada petición es un viaje a través de un bus compartido. Bajo carga,
ese bus se convierte en un problema de planificación. Añade múltiples CPUs y se vuelve un proyecto en grupo.

Compáralo con diseños posteriores con controladores de memoria integrados (AMD lo hizo antes en x86; Intel después). Cuando
acercas la memoria y le das caminos más dedicados, reduces la contención y lowers la latencia. En producción, la latencia es moneda.
NetBurst la gastó como turista.

Era SSE2/SSE3: fuerte en cálculo en streaming, desigual en otros escenarios

NetBurst se comportaba bien en algunos workloads vectorizados y de streaming—código que podía procesar arrays de forma predecible y
evitar lógica con muchas ramas. Por eso los benchmarks podían verse bien si estaban diseñados para alimentar la máquina con el tipo
de trabajo que le gustaba. Pero los servicios reales no son tan educados. Analizan, ramifican, asignan, bloquean y esperan I/O.

NetBurst era el equivalente CPU de un motor ajustado para una pista específica. Mételo en tráfico urbano y aprenderás qué significa “curva de par”.

Por qué las cargas reales duelen: cachés, ramas, memoria y espera

IPC es lo que sientes; GHz es lo que presumes

Instrucciones por ciclo (IPC) es un proxy tosco pero útil para “cuánto trabajo se hace por tic”. NetBurst a menudo
tenía menor IPC que sus contemporáneos en muchas cargas de propósito general. Así que el chip corría a mayor frecuencia para
compensar. Eso puede funcionar—hasta que no, porque:

• El código con muchas ramas dispara predicciones fallidas, que son más costosas en pipelines profundos.
• Los fallos de caché paran la ejecución, y un núcleo rápido simplemente alcanza la parada antes.
• La latencia FSB/memoria se convierte en un muro que no puedes atravesar con reloj.
• La potencia/térmicos fuerzan throttling, así que los GHz prometidos son aspiracionales.

Predicción de ramas fallida: el impuesto de latencia que sigues pagando

Las cargas de servidor están llenas de ramas impredecibles: enrutamiento de peticiones, parsing, comprobaciones de autorización, búsquedas en hash tables,
llamadas virtuales, decisiones de compresión, rutas de ejecución de bases de datos. Cuando los predictores fallan, los pipelines profundos pierden
trabajo y tiempo. La CPU no “se ralentiza”. Simplemente hace menos trabajo útil mientras está muy ocupada.

Muro de memoria: cuando el núcleo va más rápido que el sistema

NetBurst podía ejecutar rápido cuando se le alimentaba, pero muchas cargas están limitadas por la memoria. Un fallo de caché son cientos
de ciclos de espera. Ese número no es un fallo moral; es física más topología. El efecto práctico es que una CPU con más GHz puede verse peor
si alcanza stalls de memoria más frecuentemente o no puede ocultarlos eficazmente.

Desde la perspectiva del operador, esto se manifiesta como: alta utilización de CPU, throughput mediocre y un sistema que
se siente “atascado” sin saturación obvia de I/O. No está atascado. Está esperando memoria y peleándose consigo mismo.

Ejecución especulativa: útil, pero amplifica el coste de las apuestas equivocadas

La especulación es cómo las CPUs modernas obtienen rendimiento: adivina una ruta, ejecútala y descártala si está equivocada. En un pipeline profundo,
la ruta equivocada es cara. La apuesta de NetBurst fue que mejores relojes pagarían por eso. A veces lo hicieron. A menudo, no.

Una de las lecciones operacionales más simples de la era NetBurst: no trates “CPU al 95%” como “CPU hace 95% de trabajo útil”.
Necesitas contadores, no sensaciones.

Térmicos y energía: cuando la CPU negocia con la física

La densidad de potencia se convirtió en una característica del producto (por accidente)

NetBurst se calentaba. Especialmente los Pentium 4 basados en Prescott, que se hicieron notorios por consumo y calor. El calor no es solo
una factura de electricidad; es riesgo de fiabilidad, ruido de ventiladores y variabilidad de rendimiento.

En producción, los mapas térmicos se convierten en mapas de incidentes. Si un diseño exige enfriamiento intenso, tu margen desaparece:
filtros polvorientos, un ventilador fallido, una rejilla bloqueada, un pasillo cálido que sube o un rack pegado a la pared se convierten en eventos de rendimiento.
Y los eventos de rendimiento se convierten en eventos de disponibilidad.

Térmico throttling: el freno invisible

Cuando una CPU reduce frecuencia por calor, el reloj cambia, la ejecución cambia y la latencia de cola de tu servicio se desplaza de maneras que tus pruebas de carga nunca modelaron.
Con sistemas de la era NetBurst, no era raro ver “el benchmark dice X” pero “prod hace Y” porque las condiciones ambientales no estaban controladas como en un laboratorio.

Broma #1: Prescott no era un reemplazo de calentador, pero hacía las guardias de invierno un poco más soportables si te sentabas cerca del rack.

Fiabilidad y operaciones: los sistemas calientes envejecen más rápido

Capacitores, VRMs, ventiladores y placas base no aman el calor. Incluso cuando sobreviven, se desvían. Ese desvío se convierte en errores intermitentes,
reinicios espontáneos y folklore de “funciona después de volver a conectar”. Eso no es misticismo; es expansión térmica, entrega de potencia marginal
y componentes fuera de su zona de confort.

Una idea parafraseada a menudo atribuida a W. Edwards Deming aplica claramente a ops: “No puedes gestionar lo que no mides.”
Con NetBurst tenías que medir térmicos, porque la CPU seguro que lo hacía.

Hyper-Threading: el truco bueno que expuso las malas suposiciones

Hyper-Threading (SMT) llegó a algunos modelos de Pentium 4 y fue legítimamente útil en las condiciones adecuadas:
podía llenar los huecos del pipeline ejecutando otro hilo cuando uno estaba estancado. Suena como rendimiento gratis,
y a veces lo era.

Cuando ayudaba

• Cargas mixtas donde un hilo espera fallos de caché y el otro puede usar las unidades de ejecución.
• Servicios con mucho I/O donde un hilo se bloquea frecuentemente y la sobrecarga del scheduler es manejable.
• Algunos roles de servidor orientados al throughput con peticiones independientes y contención limitada de locks.

Cuando perjudicaba

• Cargas limitadas por ancho de banda de memoria: dos hilos solo compiten más por el mismo cuello de botella.
• Cargas con muchos locks: mayor contención, más rebote de líneas de caché, peor latencia de cola.
• Servicios sensibles a latencia: jitter por recursos compartidos y artefactos de scheduling.

Hyper-Threading en NetBurst es un buen microcosmos de una regla general: SMT mejora diseños buenos y empeora diseños frágiles.
Puede aumentar el throughput mientras hace la latencia más fea. Si tu SLO es p99, no “actívalo y reza”. Haz pruebas A/B con concurrencia parecida a producción y revisa la cola.

Hechos históricos que importan (y algunos que todavía duelen)

1. NetBurst debutó con Willamette (Pentium 4, 2000), priorizando velocidad de reloj sobre IPC.
2. Northwood mejoró la eficiencia y las frecuencias, y se convirtió en el Pentium 4 “menos doloroso” para muchos compradores.
3. Prescott (2004) pasó a un proceso más pequeño, añadió características y se hizo famoso por calor y consumo.
4. La “carrera de GHz” moldeó las decisiones de compra tanto que “reloj más alto” a menudo ganó a mejor arquitectura en conversaciones de ventas.
5. Acceso a memoria basado en FSB implicaba que la CPU competía por ancho de banda sobre un bus compartido hacia el northbridge.
6. Trace cache almacenaba micro-ops decodificados, buscando reducir la sobrecarga de decodificación y alimentar eficientemente la larga pipeline.
7. Hyper-Threading llegó en modelos selectos y podía mejorar throughput usando recursos de ejecución ociosos.
8. Pentium M (derivado de la línea P6) a menudo superaba a Pentium 4 con relojes mucho más bajos, especialmente en tareas del mundo real.
9. Intel finalmente pivotó lejos de NetBurst; Core (de otra línea) reemplazó la estrategia en lugar de iterarla indefinidamente.

Tres mini-historias corporativas desde las trincheras

Mini-historia 1: el incidente causado por una suposición equivocada (“GHz = capacidad”)

Una empresa mediana heredó una flota de servidores web envejecidos y planeó una renovación rápida. Los criterios de selección eran
dolorosamente simples: elegir las cajas Pentium 4 de mayor reloj dentro del presupuesto. La nota de compras literalmente equiparaba
“+20% de reloj” con “+20% de peticiones por segundo”. Nadie actuaba con malicia; estaban ocupados.

El despliegue fue fluido hasta que el tráfico alcanzó su pico normal. La utilización de CPU parecía bien—alta pero estable.
La red estaba bajo control. Los discos no gritaban. Sin embargo la latencia p95 subió y luego la p99 se disparó. El equipo on-call
hizo lo que hacen los equipos: reiniciaron servicios, movieron tráfico, culparon al balanceador y miraron gráficas hasta que las gráficas los miraron de vuelta.

El problema real fue el comportamiento de memoria. La carga había cambiado con los años: más personalización, más lógica de plantillas, más enrutamiento dinámico.
Eso significó más punteros encadenados y ramas. Los nuevos servidores tenían relojes más altos pero latencia de memoria similar y una topología FSB compartida
que empeoraba bajo concurrencia. Eran más rápidos llegando a los mismos stalls de memoria, y Hyper-Threading añadió contención en el peor momento.

La solución no fue “afinar Linux más”. La solución fue re-baselinear la capacidad usando una prueba parecida a producción:
concurrencia realista, fases de caché caliente y fría y latencia de cola como métrica de primera clase. La empresa terminó cambiando la mezcla de la flota:
menos cajas “reloj rápido”, más nodos balanceados con mejores subsistemas de memoria. También dejaron de usar GHz como número primario de capacidad.
Los milagros ocurren cuando dejas de mentirte a ti mismo.

Mini-historia 2: la optimización que salió mal (“usar HT para ganar rendimiento gratis”)

Otra compañía ejecutaba un servicio Java con muchas peticiones de corta duración. Activaron Hyper-Threading en toda la flota
y doblaron los hilos de trabajo, esperando ganancias lineales de throughput. Las pruebas sintéticas tempranas se veían geniales. Entonces llegaron
los informes de incidentes: picos de latencia esporádicos, pausas de GC alineándose con ráfagas de tráfico y un nuevo tipo de “está lento pero nada está al máximo”.

El sistema no estaba hambriento de CPU; estaba hambriento de caché y de locks. Dos CPUs lógicas compartían recursos de ejecución
y, más importante, caché compartida y rutas de ancho de banda de memoria. Los patrones de asignación y sincronización de la JVM
crearon rebotes de líneas de caché, y la mayor concurrencia amplificó la contención en hotspots que antes parecían inofensivos.

Intentaron arreglarlo aumentando el tamaño del heap, luego fijando hilos a CPUs, luego tocando perillas que se sentían “de sistemas”.
Algunas cosas ayudaron, la mayoría no. La verdadera mejora vino al dar un paso atrás: tratar Hyper-Threading como una herramienta de throughput con coste de latencia.
Mide el coste.

Revirtieron a menos hilos de trabajo, habilitaron HT solo en nodos que servían tráfico batch no interactivo y usaron perfiles de aplicación para eliminar un par de cuellos de botella de locks.
El throughput quedó ligeramente por encima de antes de la “optimización” y la latencia de cola volvió a ser aburrida. La lección no fue “HT es malo”.
La lección fue “HT es un multiplicador, y también multiplica tus errores”.

Mini-historia 3: la práctica aburrida pero correcta que salvó el día (“margen térmico es capacidad”)

Un equipo de servicios financieros ejecutaba trabajos nocturnos intensivos en cómputo en un clúster que incluía nodos Pentium 4 de la era Prescott.
A nadie le gustaban esas cajas, pero los trabajos eran estables y el clúster era “suficiente”. El superpoder silencioso del equipo era que trataban el entorno
como parte de la capacidad: monitorización de temperatura de entrada, chequeos de salud de ventiladores y alertas sobre indicadores de throttling térmico.

Un verano, una unidad de enfriamiento se degradó durante el fin de semana. No fue una caída total—solo rendimiento degradado. El lunes por la mañana
las duraciones de los trabajos subieron lentamente. La mayoría de equipos habría culpado al scheduler o a la base de datos. Este equipo notó una correlación sutil:
nodos en una fila mostraban lecturas térmicas ligeramente más altas y frecuencia efectiva de CPU ligeramente menor.

Vaciaron esos nodos, desplazaron trabajos a racks más fríos y abrieron un ticket con facilities con evidencia concreta.
También redujeron temporalmente la concurrencia por nodo para bajar la salida de calor y estabilizar los tiempos de ejecución. Sin drama, sin heroísmos,
sin sala de guerra a medianoche.

El resultado: los trabajos terminaron a tiempo, sin incidentes visibles al cliente, y el problema de enfriamiento se solucionó antes de que se convirtiera
en una fiesta de fallos de hardware. La práctica era aburrida—mide térmicos, vigila el throttling, mantiene margen—pero convirtió una “ralentización misteriosa”
en un cambio controlado. Lo aburrido está subestimado.

Tareas prácticas: 12+ comandos para diagnosticar “CPU rápida, sistema lento”

Estos son ejecutables en un servidor Linux típico. No tratas de “probar que NetBurst es malo” en 2026.
Aprendes a reconocer los mismos modos de fallo: stalls de pipeline, muro de memoria, artefactos de scheduling,
throttling térmico y utilización engañosa.

Tarea 1: Identificar la CPU y si HT está presente

cr0x@server:~$ lscpu
Architecture:            x86_64
CPU op-mode(s):          32-bit, 64-bit
CPU(s):                  2
Thread(s) per core:      2
Core(s) per socket:      1
Socket(s):               1
Model name:              Intel(R) Pentium(R) 4 CPU 3.00GHz
Flags:                   fpu vme de pse tsc ... ht ... sse2

Qué significa: “Thread(s) per core: 2” indica Hyper-Threading. El nombre del modelo te da la familia.

Decisión: Si HT está presente, haz benchmarks con HT activado/desactivado para servicios sensibles a latencia; no asumas que es una ganancia.

Tarea 2: Comprobar la frecuencia actual y el driver de escalado

cr0x@server:~$ grep -E 'model name|cpu MHz' /proc/cpuinfo | head
model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
cpu MHz		: 2793.000

Qué significa: La CPU no está a la frecuencia nominal. Podría ser ahorro de energía o throttling.

Decisión: Si la frecuencia está inesperadamente baja bajo carga, investiga governors y throttling térmico a continuación.

Tarea 3: Confirmar el governor de frecuencia de CPU

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

Qué significa: “ondemand” puede reducir la frecuencia hasta que la carga aumente; en plataformas antiguas puede responder lentamente.

Decisión: Para servicios de baja latencia, considera “performance” y vuelve a probar; para batch, “ondemand” puede estar bien.

Tarea 4: Buscar zonas térmicas y temperaturas

cr0x@server:~$ for z in /sys/class/thermal/thermal_zone*/temp; do echo "$z: $(cat $z)"; done
/sys/class/thermal/thermal_zone0/temp: 78000
/sys/class/thermal/thermal_zone1/temp: 65000

Qué significa: Las temperaturas están en miligrados Celsius. 78000 = 78°C.

Decisión: Si las temperaturas se acercan a umbrales de throttling durante picos, trata el enfriamiento como un limitador de capacidad, no como “trivia de facilities”.

Tarea 5: Detectar indicadores de throttling en logs del kernel

cr0x@server:~$ dmesg | grep -i -E 'throttl|thermal|critical|overheat' | tail
CPU0: Thermal monitoring enabled (TM1)
CPU0: Temperature above threshold, cpu clock throttled
CPU0: Temperature/speed normal

Qué significa: La CPU redujo velocidad por calor. Tu “misterio” de throughput puede ser física simple.

Decisión: Arregla flujo de aire/enfriamiento, reduce carga o reduce concurrencia. No ajustes software alrededor de un fallo térmico.

Tarea 6: Comprobar la cola de ejecución y saturación de CPU rápidamente

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 120000  15000 210000    0    0     2     5  900 1400 85 10  5  0  0
 4  0      0 118000  15000 209000    0    0     0     8 1100 1800 92  7  1  0  0

Qué significa: “r” (run queue) consistentemente por encima del número de CPUs implica contención de CPU. Bajo “id” significa ocupado.

Decisión: Si la run queue es alta, estás saturado de CPU o estancado. Siguiente: determina si es computación, memoria o locks.

Tarea 7: Identificar los principales consumidores de CPU y si están haciendo spin

cr0x@server:~$ top -b -n 1 | head -n 15
top - 12:14:01 up 21 days,  3:11,  1 user,  load average: 3.90, 3.60, 3.20
Tasks: 184 total,   2 running, 182 sleeping,   0 stopped,   0 zombie
%Cpu(s): 92.0 us,  7.0 sy,  0.0 ni,  1.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
2174 app      20   0  1856m  612m  122m R  98.7  7.6  12:11.02 java

Qué significa: Alta CPU en modo usuario puede seguir estando “esperando” (stalls de memoria, fallos de rama). “wa” bajo no despeja la CPU.

Decisión: Si un proceso domina, perfílalo; si muchos procesos comparten, sospecha contención sistémica o efectos del scheduler.

Tarea 8: Comprobar conmutaciones de contexto y presión de interrupciones

cr0x@server:~$ pidstat -w 1 5
Linux 6.1.0 (server) 	01/09/2026 	_x86_64_	(2 CPU)

12:14:20      UID       PID   cswch/s nvcswch/s  Command
12:14:21     1001      2174   1200.00    350.00  java

Qué significa: Conmutaciones de contexto muy altas pueden implicar demasiados hilos, contención de locks o churn de timers/IO.

Decisión: Si cswch/s es alto y la latencia es mala, reduce el número de hilos o arregla hotspots de locks antes de comprar hardware.

Tarea 9: Señales de estrés de ancho de banda de memoria vía perf (ciclos vs stalls frontend/backend)

cr0x@server:~$ sudo perf stat -p 2174 -e cycles,instructions,branches,branch-misses,cache-misses -a -- sleep 10
 Performance counter stats for 'system wide':

     32,100,000,000      cycles
     12,400,000,000      instructions              #    0.39  insn per cycle
      2,900,000,000      branches
        145,000,000      branch-misses             #    5.00% of all branches
        610,000,000      cache-misses

Qué significa: IPC bajo (0.39) junto con muchos fallos de caché/ramas sugiere que la CPU está ocupada pero no productiva.

Decisión: Optimiza caminos de código para localidad/predictibilidad de ramas, o elige una CPU con mejor IPC y manejo de memoria.

Tarea 10: Confirmar si realmente estás limitado por I/O

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          90.50    0.00    7.20    0.10    0.00    2.20

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await
sda              2.10    1.00   45.0    28.0     0.0     0.2    3.0    1.2

Qué significa: El disco está poco utilizado; await es bajo. Esto no es un cuello de botella de almacenamiento.

Decisión: Deja de culpar a los discos. Enfócate en CPU/memoria/locks y perfilado a nivel de petición.

Tarea 11: Revisar presión de memoria y paginación (el asesino silencioso del rendimiento)

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:            2048        1720         120          12         207         210
Swap:           2048         900        1148

Qué significa: Uso de swap puede estar bien, pero si hay paginación activa bajo carga verás stalls y picos.

Decisión: Si la actividad de swap correlaciona con latencia, reduce la huella de memoria, añade RAM o ajusta el emplazamiento de cargas.

Tarea 12: Verificar paginación activa, no solo uso de swap

cr0x@server:~$ sar -B 1 5
Linux 6.1.0 (server) 	01/09/2026 	_x86_64_	(2 CPU)

12:15:10  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgsteal/s
12:15:11      0.00      0.00    820.00      0.00   1200.00      0.00      0.00
12:15:12     10.00     45.00   2100.00     15.00    400.00    800.00    300.00

Qué significa: Fallos mayores (majflt/s) y escaneos indican presión real de memoria.

Decisión: Paginación bajo carga es un problema de capacidad. Arregla memoria, no flags de CPU.

Tarea 13: Inspeccionar la presión del scheduler de un vistazo

cr0x@server:~$ cat /proc/pressure/cpu
some avg10=12.34 avg60=10.01 avg300=8.55 total=987654321

Qué significa: CPU PSI “some” indica tiempo que las tareas pasan esperando recursos de CPU.

Decisión: Si PSI sube con la latencia, necesitas CPU más efectiva (IPC), menos threads ejecutables o degradación de carga.

Tarea 14: Detectar contención de locks (a menudo mal diagnosticada como “CPU lenta”)

cr0x@server:~$ sudo perf top -p 2174
Samples: 31K of event 'cpu-clock', 4000 Hz, Event count (approx.): 7750000000
Overhead  Shared Object        Symbol
  12.40%  libc.so.6            [.] pthread_mutex_lock
   9.10%  libjvm.so            [.] SpinPause

Qué significa: El tiempo se va en locking y spinning, no en trabajo productivo.

Decisión: Reduce la contención (shard locks, reduce threads, arregla secciones críticas calientes). Más GHz no te salvará.

Tarea 15: Validar la afinidad de caché mediante un microbenchmark rápido (no sustituye pruebas reales)

cr0x@server:~$ taskset -c 0 sysbench cpu --cpu-max-prime=20000 run
CPU speed:
    events per second:  580.21

General statistics:
    total time:                          10.0004s
    total number of events:              5804

Qué significa: Una prueba intensiva de cómputo puede verse “bien” incluso si tu servicio está limitado por memoria/ramas.

Decisión: Usa microbenchmarks solo para una comprobación de cordura; basa decisiones en tests representativos de la carga y latencia.

Broma #2: Si tu plan es “añadir hilos hasta que vaya rápido”, no estás optimizando—estás invocando demonios de contención.

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

Este es el atajo de grado producción para sorpresas tipo NetBurst: sistemas que parecen “ricos en CPU” en papel pero actúan
lentos en cargas reales. Quieres el cuello de botella rápido, no un debate filosófico sobre microarquitectura.

Primero: verifica que la CPU que crees tener sea la que estás recibiendo

1. Frecuencia bajo carga: comprueba /proc/cpuinfo MHz, el governor y dmesg por throttling.
2. Térmicos: revisa zonas térmicas y el estado de ventiladores/flujo de aire vía la telemetría disponible.
3. Virtualización: confirma que no estás limitado por cuotas de CPU o vecinos ruidosos (PSI, cgroups).

Objetivo: eliminar “la CPU literalmente no está corriendo a la velocidad esperada” en 5 minutos.

Segundo: determina si estás limitado por computación, memoria o contención

1. Run queue y PSI: vmstat y /proc/pressure/cpu para espera de CPU.
2. perf IPC: ciclos vs instrucciones; IPC bajo sugiere stalls/fallos.
3. Señales de contención de locks: perf top, pidstat context switches, volcados de hilos de la aplicación.

Objetivo: clasificar el dolor. No puedes arreglar lo que no nombras.

Tercero: confirma que no es I/O ni paginación

1. Disco: iostat -xz para utilización y await.
2. Paginación: sar -B para fallos mayores y actividad de escaneo.
3. Red: revisa drops/errores y colas (no mostrado arriba, pero deberías hacerlo).

Objetivo: dejar de perder tiempo en el subsistema equivocado.

Cuarto: decide si es un problema de encaje de hardware o de software

• Si el IPC es bajo por fallos de caché y branch misses, necesitas mejor localidad o una CPU con mejor IPC—no más GHz.
• Si domina la contención, reduce la concurrencia o rediseña los caminos calientes—mejorar hardware no arreglará código serializado.
• Si hay throttling, arregla primero el enfriamiento y la entrega de potencia; de lo contrario cada otro cambio es ruido.

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

1) Síntoma: “La CPU está al límite, pero el throughput es mediocre”

Causa raíz: IPC bajo por fallos de caché, predicciones de rama o latencia de memoria; la CPU parece ocupada pero está estancada.

Solución: Usa perf stat para confirmar IPC bajo y altos fallos; luego optimiza para localidad, reduce pointer chasing y perfila los caminos calientes. Si vas a comprar hardware, prioriza IPC y subsistema de memoria, no reloj.

2) Síntoma: “Los picos de latencia aparecen solo en tardes calurosas / después de cambiar un ventilador”

Causa raíz: Throttling térmico o flujo de aire pobre causando caídas de frecuencia y jitter.

Solución: Confirma mediante dmesg y lecturas de zonas térmicas; remedia el enfriamiento, limpia filtros, verifica curvas de ventiladores y mantiene margen de temperatura de entrada. Trata los térmicos como dependencia de primer orden del SLO.

3) Síntoma: “Habilitamos Hyper-Threading y la p99 empeoró”

Causa raíz: Contención de recursos en unidades de ejecución/cachés compartidas, mayor contención de locks o saturación de ancho de banda de memoria.

Solución: Prueba A/B HT on/off con concurrencia parecida a producción; reduce hilos; arregla hotspots de locks; considera HT solo para cargas orientadas a throughput o I/O.

4) Síntoma: “Los microbenchmarks mejoraron, la producción se volvió más lenta”

Causa raíz: Los microbenchmarks son intensivos y predecibles; producción es ramificada y dependiente de memoria. Diseños tipo NetBurst recompensan lo primero y castigan lo segundo.

Solución: Mide con mezclas de peticiones realistas, fases de caché caliente/fría y latencia de cola. Incluye concurrencia, comportamiento del asignador y tamaños de datos realistas.

5) Síntoma: “El load average aumentó después de ‘optimizar’ añadiendo hilos”

Causa raíz: Sobre-suscripción y contención; más hilos ejecutables incrementan overhead de scheduling y locking.

Solución: Usa pidstat para medir context switches, perf top para símbolos de lock y reduce concurrencia. Añade paralelismo solo donde el trabajo es paralelo y el cuello de botella se mueve.

6) Síntoma: “Las actualizaciones de CPU no ayudaron a la base de datos”

Causa raíz: La carga está limitada por latencia de memoria o ancho de banda (fallos en buffer pool, pointer chasing en B-trees, cache misses).

Solución: Aumenta la tasa de aciertos de caché efectiva (índices, forma de consultas), añade RAM, reduce el working set y mide misses/IPC. No lances GHz contra un muro de memoria.

7) Síntoma: “Todo parece bien salvo pausas ocasionales y timeouts”

Causa raíz: Paginación, pausas de GC o picos de contención que no aparecen como utilización sostenida.

Solución: Revisa fallos mayores, PSI y métricas de pausa de la aplicación. Arregla presión de memoria y reduce la amplificación de cola (timeouts, reintentos, thundering herds).

Listas de verificación / plan paso a paso

Checklist A: Comprar hardware sin repetir el error NetBurst

1. Define el éxito como latencia y throughput (p50/p95/p99 + RPS sostenido), no la velocidad de reloj.
2. Mide proxies de IPC: usa perf en cargas representativas; compara ciclos/instrucciones y tasas de fallos.
3. Modela comportamiento de memoria: tamaño del working set, tasas de acierto de caché, concurrencia esperada y necesidades de ancho de banda.
4. Valida térmicos: prueba en rack, con temperatura ambiente realista y perfiles de ventiladores.
5. Prueba impacto de SMT/HT: on/off, con conteos reales de hilos y seguimiento de latencia de cola.
6. Prefiere sistemas balanceados: canales de memoria, tamaños de caché e interconexión importan tanto como los relojes de los cores.

Checklist B: Cuando un despliegue de “CPU más rápida” hace prod más lenta

1. Confirma frecuencia y throttling (governor, temperaturas, dmesg).
2. Compara perf IPC y tasas de fallos antes/después.
3. Revisa conteos de hilos y context switching; revierte primero los cambios de “doblar hilos”.
4. Valida presión de memoria y paginación; arregla fallos mayores inmediatamente.
5. Busca regresiones de contención de locks introducidas por la nueva concurrencia.
6. Si aún no está claro, captura un flame graph o artefacto de profiling y revísalo como una línea de tiempo de incidente.

Checklist C: Estabilizar latencia de cola en sistemas viejos, calientes y con persecución de frecuencia

1. Reduce la concurrencia para que coincida con los cores (especialmente con HT) y observa el impacto en p99.
2. Afina la afinidad de hilos solo si conoces tu topología; de lo contrario te puedes encerrar en una esquina.
3. Mantén el governor de CPU consistente (a menudo “performance” para nodos críticos de latencia).
4. Haz cumplir margen térmico: alerta por temperatura y eventos de throttling, no solo por utilización de CPU.
5. Optimiza caminos calientes para localidad; elimina ramas impredecibles cuando sea posible.
6. Introduce backpressure y timeouts razonables para evitar tormentas de reintentos.

Preguntas frecuentes

1) ¿Fue Pentium 4 realmente “malo” o solo malentendido?

Fue una apuesta estrecha. En cargas que coincidían con sus puntos fuertes (streaming, código predecible y alto apalancamiento de reloj),
podía rendir bien. En cargas mixtas de servidor, a menudo entregaba peor rendimiento real por vatio y por dólar que alternativas. “Malentendido” es generoso; “mal vendido” está más cerca.

2) ¿Por qué más GHz no se tradujo en más rendimiento?

Porque el rendimiento depende del trabajo útil por ciclo (IPC) y de con qué frecuencia te atas en memoria, ramas y contención.
NetBurst aumentó el conteo de ciclos pero a menudo redujo el trabajo útil por ciclo en cargas reales.

3) ¿Cuál es la lección operativa para sistemas modernos?

No aceptes una sola métrica de titular. Para CPUs es GHz; para almacenamiento es “IOPS”; para redes es “Gbps”.
Pregunta siempre: ¿bajo qué latencia, con qué concurrencia y con qué comportamiento de cola?

4) ¿Hyper-Threading “arregló” NetBurst?

Ayudó en throughput en algunos casos llenando ranuras de ejecución ociosas, pero no cambió los fundamentos:
penalizaciones por pipeline profundo, cuellos de botella de memoria y limitaciones térmicas. También podía empeorar la latencia de cola añadiendo contención.
Trátalo como un ajuste, no como un valor por defecto bueno.

5) ¿Por qué Pentium M a veces vencía a Pentium 4 con relojes mucho más bajos?

Pentium M (de la estirpe P6) enfatizaba IPC y eficiencia. En cargas con muchas ramas y sensibles a caché, un IPC más alto
junto con mejor eficiencia a menudo vence a la frecuencia bruta, especialmente cuando el reloj provoca throttling de potencia y térmico.

6) ¿Cómo puedo saber si mi carga está limitada por memoria en vez de por CPU?

Busca IPC bajo con muchos fallos de caché en perf, además de mejora limitada al añadir cores o subir frecuencia.
También verás plateau de throughput mientras la CPU se mantiene “ocupada”. Eso suele ser un muro de memoria o de contención.

7) ¿Es el throttling térmico lo suficientemente común como para importar?

En diseños que corren calientes y en datacenters reales, sí. Incluso throttling modesto crea jitter. El jitter se convierte en latencia de cola,
y la latencia de cola se convierte en incidentes cuando reintentos y timeouts amplifican la carga.

8) ¿Qué debo benchmarkear para evitar errores de la era GHz?

Mide el servicio real: mezcla de peticiones realista, tamaño de datos realista, concurrencia realista e informa p95/p99 de latencia además de throughput.
Añade una fase de caché fría y una ejecución sostenida lo suficientemente larga para calentar el sistema.

9) ¿Existen equivalentes modernos de la trampa NetBurst?

Sí. Cualquier vez que optimices una métrica pico a costa del comportamiento sistémico: frecuencias turbo sin presupuesto térmico, benchmarks de almacenamiento
que ignoran latencia de fsync o pruebas de red que ignoran pérdida de paquetes bajo carga. El patrón es el mismo: el pico gana en la presentación, la cola pierde al cliente.

Conclusión: qué hacer la próxima vez que te vendan GHz

NetBurst no es solo trivia retro de CPUs. Es una historia clara sobre incentivos, medición y el coste de apostar
a un solo número. Intel optimizó para frecuencia porque el mercado pagaba por frecuencia. Las cargas que importaban—
código con muchas ramas, sistemas pesados en memoria, racks con restricciones térmicas—enviaron la factura.

Los siguientes pasos prácticos son aburridos, y por eso funcionan:

1. Define el rendimiento usando latencia de cola, no el pico de throughput y definitivamente no la velocidad de reloj.
2. Instrumenta para cuellos de botella: contadores perf, PSI, métricas de paginación y señales térmicas/de throttling.
3. Benchmarkea como en producción: concurrencia, tamaño de datos, comportamiento de caché, heat soak y mezclas de peticiones realistas.
4. Trata los térmicos como capacidad: si la CPU hace throttling, tu arquitectura está “limitada por enfriamiento”. Acéptalo.
5. Sospecha de “rendimiento gratis”: HT/SMT, concurrencia agresiva y micro-optimizaciones que ignoran la contención.

Si recuerdas solo una cosa: los relojes son un componente, no una garantía. El sistema es el producto. Operalo como tal.