Detección de ancho de banda de memoria en servidores en la nube: por qué se reduce la velocidad aunque la capacidad sea suficiente

Tener suficiente capacidad no significa tener suficiente ancho de banda; se necesita una triple verificación para verlo con claridad.

Actualizado 2026-10-07 · CloudWorth

Ancho de banda de memoriaSTREAMNUMADetección de sobreventaFinOpsCloudWorthSteal TimeSobreventa VPSBenchmark VPS

La capacidad adecuada no garantiza un ancho de banda adecuado; realiza una verificación cruzada con STREAM, Steal Time y afinidad NUMA, y luego decide si actualizar o solicitar reembolso según la tasa de sobreprecio.

Mide primero la capacidad y luego el ancho de banda

Al comprar un servidor en la nube, casi todo el mundo se fija primero en la capacidad de memoria: 8 GB, 16 GB, 32 GB. La capacidad aparece en la página del pedido, se ve y cuadra, así que se asume por defecto que «la memoria está bien». Pero la capacidad es solo la superficie del almacén; el ancho de banda es la velocidad de la carretilla elevadora: una instancia de 8 GB puede perfectamente tener la capacidad en verde y, aun así, un rendimiento de memoria de solo la mitad del nominal de su generación.

Este es el escenario clásico de capacidad conforme pero velocidad degradada: cargas de trabajo como inferencia de IA, búsqueda vectorial, valores grandes de Redis o copias dentro del heap de la JVM son mucho más sensibles a los GB/s que a los GB; aunque la capacidad sea suficiente, chocan antes con el techo del ancho de banda.

Primero, separa los dos aspectos:

1. Lado de capacidad: con free -h revisa total/available y coteja con las especificaciones del pedido para confirmar que no haya una recuperación oculta del controlador balloon. En KVM puedes comprobarlo con dmesg | grep -i balloon.
2. Lado del ancho de banda: que la capacidad cuadre no significa que el ancho de banda cuadre; hace falta una prueba específica de rendimiento de memoria, que se explica en la siguiente sección.

El orden debe ser primero capacidad y luego ancho de banda. Si la capacidad no cumple, es una especificación falsa: pide el reembolso directamente. Si la capacidad cumple pero el ancho de banda cae, ese es el problema más oculto de sobreventa / limitación de velocidad, y requiere la siguiente cadena de pruebas.

Un criterio empírico: si compras una instancia de «igual capacidad pero claramente un escalón más barata», asume por defecto que el ancho de banda es sospechoso, en lugar de dar por hecho que encontraste una ganga. Este tipo de gangas suelen venir de sobreasignación de CPU, distribuciones NUMA entre nodos o reducción de la frecuencia de memoria, y acaban pasándote factura en forma de tasa de sobreprecio de la relación precio-rendimiento: compraste capacidad, pero no rendimiento.

Cuando hayas registrado los datos brutos (especificaciones de la instancia, región, imagen, tipo de facturación, hora del pedido), pasa a las pruebas reales. El registro en sí es la evidencia para los futuros tickets y para decidir una reducción de configuración; un ticket en el que solo escribas «la memoria es muy lenta» casi nunca se tramitará de forma efectiva.

Pruebas reales de STREAM y sysbench

La comprobación del ancho de banda de memoria tiene dos conjuntos de herramientas complementarias: STREAM mide el rendimiento vectorial sostenido (Copy/Scale/Add/Triad), sysbench memory mide escenarios más cercanos a «lectura/escritura de bloques pequeños». La discusión sysbench vs STREAM memory bandwidth test for cloud servers no tiene sentido; hay que ejecutar ambos, porque sus direcciones de distorsión son distintas: STREAM es demasiado benévolo con la caché L3 de instancias pequeñas, sysbench es demasiado sensible al coste de instrucciones; solo mirándolos de forma cruzada se evita que un único número nos engañe.

Uso de STREAM (se puede compilar en el directorio home sin root):

sudo apt install -y gcc gfortran make
# 下载 stream.c 后：
gcc -O3 -fopenmp -DSTREAM_ARRAY_SIZE=200000000 stream.c -o stream
OMP_NUM_THREADS=$(nproc) ./stream

El tamaño del array se establece en 1/4～1/2 de la memoria; si es demasiado pequeño, todo caerá en la caché y se obtendrá un «ancho de banda inflado»; de lo contrario, se está midiendo L3, no DRAM.

Por el lado de sysbench:

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write run

Tres puntos clave para el juicio:

• Mononúcleo vs todos los núcleos: ejecutar por separado taskset -c 0 y todos los núcleos, registrar GB/s. Si con todos los núcleos apenas aumenta, indica que el ancho de banda ya está limitado, no que falten núcleos.
• Comparar con lo nominal: la diferencia generacional entre DDR4 y DDR5 es de aproximadamente 1,5～2 veces; entre instancias en la nube de la misma generación y misma frecuencia no debería haber diferencias de dos o tres veces; si aparece, es anómalo.
• Convertir a ancho de banda por vCPU: ancho de banda total / número de vCPU es la métrica más práctica para juzgar la sobreventa de ancho de banda de memoria. El ancho de banda per cápita de las instancias compartidas suele ser solo la mitad que el de las dedicadas, y esta es una de las verdaderas fuentes de la tasa de sobreprecio de servidores en la nube.

Ejecutar tres veces y tomar la mediana, evitando las horas punta de vecinos. Para convertir automáticamente estos números en ancho de banda per cápita y tasa de sobreprecio, puedes crear una plantilla en /app, introducir STREAM, sysbench y el precio de la instancia juntos, y generar un perfil de relación calidad-precio comparable. La siguiente sección utiliza Steal Time y NUMA para atribuir la «caída de velocidad» a causas concretas.

Steal Time y análisis forense de NUMA

La sección anterior solo puede demostrar que «ha bajado la velocidad»; la atribución aún depende de otros dos indicadores: Steal Time y topología NUMA. Esta es también la capa que más se omite en la detección de ancho de banda de memoria en servidores en la nube: la capacidad es suficiente y una ejecución individual también cumple, pero el cuello de botella se esconde en la planificación y la afinidad de memoria. Las páginas de configuración nominal nunca mencionan estos dos elementos, y la diferencia en las puntuaciones reales suele estar precisamente aquí.

Primero, veamos st:

vmstat 1 10        # 盯 st 列（Steal Time）
mpstat -P ALL 1    # 逐核 %steal

Si st se mantiene >3% durante mucho tiempo y coincide con la caída del ancho de banda, significa que el tiempo de vCPU está siendo tomado prestado por los vecinos. En KVM compartido, la correlación entre el robo de CPU y el ancho de banda de memoria es altísima; lo que cae es toda la ruta, no solo la capacidad de cómputo.

Ahora veamos NUMA:

lscpu | grep -i numa
numactl --hardware
numactl --cpunodebind=0 --membind=0 \
  sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read run

Si tras vincular el proceso al nodo local el ancho de banda se recupera claramente, se trata de una penalización entre nodos (habitual del 20%～40%), no de sobreventa; si después de vincularlo sigue pegado al techo de ancho de banda por usuario, entonces sí es una limitación real.

Llevar capturas de st, la topología NUMA y el ancho de banda antes y después de la vinculación para abrir un ticket es mucho más eficaz que decir sin más «se ha vuelto más lento». Si quieres consolidarlo en una plantilla forense reutilizable, puedes poner estos tres números junto con el precio unitario que pagas en /app, calcular bien la tasa de sobreprecio y luego decidir si ampliar la configuración, cambiar de zona de disponibilidad o iniciar el proceso de reembolso.

Verificación del acantilado de caché de disco

Tras el enlace NUMA, el ancho de banda sigue pegado al techo; falta una última prueba: usar el acantilado de caché para separar «memoria lenta» de «disco lento». El método es leer primero en caliente y luego en frío el mismo archivo, y ver en qué tamaño de conjunto de trabajo cae el ancho de banda.

# 1) 热路径：让 page cache 命中，测的是缓存速度
fio --name=hot --filename=/data/blob --rw=read --bs=1M \
    --size=4G --direct=0 --runtime=30 --time_based

# 2) 冷路径：清缓存后测真实内存→IO 通路
sync && echo 3 > /proc/sys/vm/drop_caches
fio --name=cold --filename=/data/blob --rw=read --bs=1M \
    --size=4G --direct=1 --runtime=30 --time_based

Puntos clave para interpretar:

• El ancho de banda de lectura en frío, al pasar el conjunto de trabajo de 256M a 4G, muestra una disminución suave, que es el comportamiento normal de la jerarquía de memoria y del prefetch;
• Si cae formando un acantilado (por ejemplo, se reduce a la mitad alrededor de 2G), y el punto de quiebre es mucho menor que el L3/caché esperado según las especificaciones de la instancia, normalmente indica que el ancho de banda de memoria está siendo limitado, y no que el disco se esté quedando corto primero;
• De paso, observa bi/bo y si/so en vmstat 1; si la IO no es alta pero el rendimiento cae en picado, el problema está casi con seguridad del lado de la memoria.

Este es también el punto donde más fácilmente se fracasa al comparar «benchmark real vs configuración nominal»: una instancia de 8GB con DDR4/DDR5 y capacidad nominal no está mal, pero en cuanto el KV cache de inferencia de IA o la búsqueda vectorial expulsan el conjunto de trabajo de la caché, el ancho de banda cae primero y la latencia empieza a oscilar inmediatamente. Pon el punto del acantilado, el ancho de banda antes y después del enlace NUMA, y %steal —los tres números— junto con el precio unitario que realmente pagas para calcular la tasa de sobrecoste, y luego decide si ampliar, cambiar de zona de disponibilidad o solicitar reembolso; es mucho más eficaz que reiniciar una y otra vez. Si necesitas una plantilla de evidencias ya hecha, puedes aplicarla directamente en /app.

En una frase: cumplir con la capacidad es solo el ticket de entrada; en la comprobación del ancho de banda de memoria de un servidor en la nube, lo que importa es dónde está el punto de inflexión de la caída de velocidad y a qué precio sigues pagando después de ese punto.

Comparativa de benchmarks y decisión de sobreprecio

En los apartados anteriores ya hemos obtenido tres conjuntos de datos duros: el Copy/Triad de STREAM, la diferencia de ancho de banda antes y después de la vinculación NUMA, y la curva de %steal. Ahora solo falta el último paso: alinearlos con la factura. El método es muy sencillo: escribe en dos columnas lo de «nominal vs. medido» de la misma instancia:

# 实测带宽（GB/s）
sysbench memory --memory-block-size=1M --memory-total-size=10G run | grep transferred
# 单价（元/GB 内存/月）= 月费 / 标称容量
# 性价比 = 实测带宽 / 单价

Los criterios de interpretación pueden ser algo gruesos, pero deben ser numéricos:

• El ancho de banda medido alcanza más del 70% de los valores públicos de DDR4/DDR5 de la misma generación y %steal está normalmente por debajo del 2%: es un recurso compartido normal, sigue usándolo;
• El ancho de banda solo está entre el 50% y el 70% de lo esperado según lo nominal, y la vinculación NUMA puede recuperar un 15%+: es un problema de planificación; cambiar de zona de disponibilidad o especificar la afinidad de vCPU suele ser más barato que subir de plan;
• El ancho de banda está por debajo del 50%, %steal se mantiene por encima del 5% durante periodos largos y el acantilado de Cache aparece antes de lo previsto: esta es la señal típica de sobreventa de VPS; es la prueba concluyente de la detección de sobreventa de servidores cloud.

Calcula la relación rendimiento-precio antes de plantear acciones. Supón que una instancia de 8 GB cuesta 120 yuanes al mes y que el ancho de banda medido solo es el sesenta por ciento del de una instancia AMD EPYC al mismo precio; entonces tu tasa de sobreprecio es en realidad del 40%. En ese caso, ampliar a 16 GB a menudo solo amplifica el «cada GB es más caro»; cambiar de tipo de instancia o solicitar el reembolso suele ser más rentable. Calcula la tasa de sobreprecio antes de actualizar y guarda pruebas antes de pedir el reembolso: envía juntos la salida original de los tres benchmarks, el %steal de vmstat y una captura de numactl --hardware; en el ticket escribe solo datos, no adjetivos, y las probabilidades de que te den la razón son mucho mayores. Ejecuta la misma prueba antes de renovar, para evitar que en la renovación te bajen las especificaciones a escondidas. La tabla completa de recopilación de pruebas y la plantilla de ticket están en /guides/memory-bandwidth-checklist; puedes copiarlas directamente.

Recuerda la conclusión: cumplir con la capacidad no significa cumplir con el ancho de banda. Usa STREAM junto con Steal Time y la vinculación NUMA para hacer una validación cruzada, y después compara con la tasa de sobreprecio para decidir si conviene ampliar o pedir el reembolso.