Pruebas de rendimiento y configuraciones falsas en servidores en la nube: cómo identificar y evitar CPU antiguas

Triple evidencia para desenmascarar la mentira de la prima de las CPU antiguas

Actualizado 2026-08-25 · CloudWorth

pruebas de rendimientoespecificaciones falsasSteal Timesobreventarelación calidad-precioCloudWorthSobreventa VPSBenchmark VPS

Usa Steal Time + caché de disco + pruebas de rendimiento reales como triple verificación; no pagues más por CPU antiguas.

¿Cuánto se aleja el rendimiento real de las especificaciones?

La diferencia entre el rendimiento de un servidor en la nube y su configuración especificada suele ser mayor de lo que se imagina. Especialmente en el caso de CPUs antiguas que presumen de "alta frecuencia", como los Xeon E5-2690 v4 y E5-2680 v4 de alrededor de 2016, la frecuencia de un solo núcleo parece alta, pero al probar un solo hilo, el puntaje puede ser solo la mitad del de un Xeon de nueva generación. Las principales causas de este "rendimiento inflado" son dos: la diferencia generacional del hardware y el aumento del Steal Time debido a la sobreventa.

Después de virtualizar una plataforma antigua, el campo steal en /proc/stat te dice el tiempo que la CPU es tomada por el hypervisor. Si con mpstat -P ALL 1 ves que el %steal supera el 10% durante un largo período, significa que los vecinos están disputando contigo los recursos; en ese caso, no importa cuán alta sea la especificación, el rendimiento será inestable. Otro indicador encubierto es la caída abrupta de la caché de disco: en el almacenamiento antiguo con CPUs antiguas, una vez que la caché se agota, la IOPS cae a la mitad directamente, y la curva de rendimiento muestra una caída evidente.

Para cuantificar la diferencia, puedes ejecutar yabs o sysbench cpu --threads=1 run y comparar con las especificaciones oficiales. Me he encontrado con plataformas antiguas de 3.5 GHz nominales que, en la prueba de un solo núcleo, rinden un 40% menos que una plataforma nueva de 2.9 GHz. Es decir, el dinero que pagas por "alta frecuencia + configuración antigua" podría ser en gran parte una prima por hardware de segunda mano. Este es el ejemplo más típico de costo negativo en FinOps: con el mismo presupuesto, elegir una plataforma nueva o instancias oficialmente certificadas reduce el costo unitario de cómputo.

Así que no te fijes solo en los parámetros nominales. Se recomienda filtrar las instancias en CloudWorth según el rendimiento real y el umbral de Steal Time, y gastar el presupuesto en rendimiento verdadero.

Steal Time: destapando la sobreventa

Para desenmascarar las especificaciones infladas de los servidores en la nube, el primer corte va dirigido al steal time. Esta métrica es la señal con la que el hipervisor te saluda: cuando la CPU física es cedida por el hipervisor a la máquina virtual vecina, tus vCPUs solo pueden esperar. Usa top, pulsa C para cambiar a la lista de CPUs, luego t para ver la columna steal, o ejecuta directamente vmstat 1 para observar el campo st. Muestrea durante varios minutos; si el promedio de st supera el 5%, o incluso hay picos que llegan al 20%+, enhorabuena, estás compartiendo el mismo núcleo físico con un grupo de vecinos ruidosos.

# 连续采样 10 次，每次间隔 1 秒，取 st 平均值
vmstat 1 10 | awk 'NR>3 {sum+=$16} END {print "avg steal:", sum/(NR-3), "%"}'

Los picos de Steal Time son más alarmantes que un valor alto constante: indican que la sobreventa es dinámica y que en las horas punta tu tiempo de respuesta se agita de forma aleatoria como un electrocardiograma. Combinado con el desplome de la caché de disco mencionado en la sección anterior, esto confirma que se trata de un host físico antiguo que ha sido subarrendado repetidamente.

Desde la perspectiva de FinOps, esto es un típico fraude de sobreprecio: pagas el precio de un hardware nuevo, pero recibes las sobras de una CPU antigua cortada en pedazos, con un sobreprecio que casi triplica el de la nube pública. No te dejes engañar por la alta frecuencia; por muy potente que sea un solo núcleo de un Xeon antiguo, no puede contra los vecinos que se le adelantan. Antes de hacer benchmark, mira primero el steal; de lo contrario, por muy bonitos que sean los números de Geekbench, solo son un espejismo en el arenero de la sobreventa. Esta métrica es gratuita y reproducible, más honesta que cualquier promesa del proveedor.

Evidencia de la caída de la caché de disco

Antes usábamos Steal Time para detectar la sobreventa, pero algunos centros de datos antiguos mantienen la programación de la CPU muy nivelada, por lo que los datos de Steal no parecen malos. En ese caso, no te apresures a sacar conclusiones: dirige tu atención a la caché de disco, que es uno de los componentes que menos miente.

En la práctica, suelo usar fio para ejecutar dos rondas consecutivas: primero, la escritura con búfer (buffered) que utiliza la Page Cache, y luego, la escritura directa que evita la caché. Los comandos son más o menos así:

# Primera ronda: escritura con búfer (usa la caché de memoria)
fio --name=cache-test --rw=write --bs=1M --size=2G --direct=0 --ioengine=libaio --runtime=30 --time_based

# Segunda ronda: escritura directa (evita la caché, escritura directa al disco)
fio --name=direct-test --rw=write --bs=1M --size=2G --direct=1 --ioengine=libaio --runtime=30 --time_based

Lo clave es observar la "proporción de caída" entre los valores de las dos rondas. En discos en la nube NVMe nuevos, la escritura directa suele estar en torno al 60 %–80 % de la escritura con búfer; en discos mecánicos antiguos o almacenamiento compartido, la escritura directa puede caer por debajo del 10 %. Si se anuncia una velocidad de 2000 MB/s, pero la escritura directa solo alcanza 150 MB/s, eso es una típica caída de la caché: los datos te engañan primero, y la realidad aparece al escribir en el disco.

Esta evidencia debe analizarse junto con Steal Time. Un Steal alto indica que los vecinos están compitiendo por la CPU, y la caída en el disco indica que el canal de almacenamiento también está saturado. Con ambos indicadores, se puede determinar que hay sobreventa, y no una sobreventa cualquiera, sino una en la que incluso el hardware subyacente está obsoleto.

Desde la perspectiva de FinOps, este tipo de máquinas debería valorarse por su "valor residual". Si la prima sobre el precio correspondiente a la configuración anunciada supera el 30 % de una máquina nueva, se descarta directamente; si no se puede negociar, se cambia. Después de todo, pagas por la spec, no por un espejismo en la caché. La lista completa para evitar trampas está en la Guía de autocomprobación de especificaciones infladas en servidores en la nube.

Árbol de decisión sobre el sobreprecio y cómo evitar trampas

Cuando consigas un servidor en la nube con una \"CPU antigua de alta frecuencia\", no te apresures a pagar. Primero calcula la tasa de sobreprecio: (pago mensual real - precio de mercado de un nuevo CPU con la misma configuración) / precio de mercado de un nuevo CPU con la misma configuración. Si el sobreprecio supera el 30%, básicamente puedes concluir que estás pagando un impuesto por ser tonto por hardware retirado. Una jugada más agresiva es cuantificarlo directamente desde la perspectiva de FinOps: ¿con el mismo dinero puedes comprar el doble de núcleos de un AMD EPYC o un Intel nuevo de 3 años? Si se puede, significa que esta compra no debería aprobarse.

A continuación, sigue mi árbol de decisión forense de tres pasos:

1. Steal Time para detectar malos vecinos

   vmstat 1 10 | awk '{print $17}'  # ver la columna st

Si en el muestreo continuo el promedio de st es > 5%, o aparecen picos superiores al 20%, indica que el host está gravemente sobrevendido, el tiempo de CPU está siendo robado por los vecinos, y reducir la configuración es la única forma de detener las pérdidas.

1. Prueba de caída abrupta de la caché de disco

   dd if=/dev/zero of=/tmp/test bs=1M count=1024 conv=fdatasync

La primera vez escribe en caché a 1.5 GB/s, la segunda vez cae a 150 MB/s, la caché se desinfla, típica sobreventa de almacenamiento compartido. Configuración antigua + caída de disco = doble especificación inflada.

1. Comparación de benchmarks reales

   curl -sL yabs.sh | bash

¿Geekbench 5 de un solo núcleo por debajo de 700, pero con una frecuencia nominal de 3.5 GHz? Lleva este informe directamente al servicio al cliente y exige un reembolso por la diferencia de precio con un nuevo CPU de 4 núcleos o una migración.

Finalmente, una regla dura: cualquier página promocional que afirme \"alto rendimiento\", pero que no proporcione un enlace a resultados de benchmarks reales en la preventa, se tratará como especificaciones infladas. Solo confía en tus propios resultados de benchmark y paga el sobreprecio solo por CPUs nuevos.