Cómo medir bien el rendimiento de un VPS

Qué significa comparar el rendimiento de un VPS

Para comparar el rendimiento de un VPS, mida cuatro aspectos: la velocidad de un solo núcleo de CPU, el ancho de banda de memoria disponible, el número de operaciones pequeñas y aleatorias de disco que el almacenamiento atiende por segundo y el rendimiento que ofrece el enlace de red. Una ejecución de yabs.sh proporciona los cuatro datos en unos diez minutos. Interpretar el resultado es más difícil, porque un VPS (servidor privado virtual) comparte el hardware físico con otros clientes. Por eso, la misma máquina puede mostrar un valor a las 03:00 y uno muy diferente a las 20:00.

El plan consiste en ejecutar yabs.sh para obtener una visión rápida y después ejecutar manualmente las herramientas que utiliza internamente. Ejecutarlas usted mismo permite cambiar un indicador, observar cómo cambia el valor y entender qué estaba midiendo realmente. Hágalo después de configurar la máquina, no antes. Los pasos de los primeros diez minutos en un VPS nuevo van primero, porque un servidor que todavía está aplicando su primera tanda de actualizaciones produce resultados de referencia deficientes por motivos que no tienen relación con el hardware.

Observe la máquina antes de medirla

La mitad de los benchmarks defectuosos se deben a que el autor no entendió la máquina.

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM significa virtualización completa, por lo que ejecuta su propio kernel. Que systemd-detect-virt muestre lxc o openvz significa que se usa virtualización mediante contenedores: comparte el kernel del host, y los límites de CPU y memoria son configuraciones de cgroup (grupo de control), no hardware virtual. En un sistema con cgroup v2 puede leer directamente el límite de CPU.

cat /sys/fs/cgroup/cpu.max

max 100000 significa que no hay cuota. 200000 100000 significa que puede usar 200000 microsegundos de CPU en cada periodo de 100000 microsegundos, lo que equivale a una cuota de dos núcleos. Un plan anunciado como 4 vCPU con una cuota de dos núcleos nunca obtendrá resultados equivalentes a cuatro núcleos, y ninguna herramienta de benchmark muestra una línea que explique el motivo.

df -hT / importa por otro motivo: la columna Type. Si muestra overlay, está dentro de un contenedor y la prueba de disco siguiente necesita un cambio. Téngalo en cuenta ahora.

Supervise el steal time durante toda la prueba

El steal time es el porcentaje de tiempo durante el que la CPU virtual estaba lista para ejecutarse, pero el hipervisor asignó el núcleo físico a otra máquina virtual. Es la señal individual más útil para determinar si un resultado se debe a otras máquinas virtuales del host y no al hardware.

vmstat 1 10

Lea la columna st de la derecha. Un valor estable de 0 o 1 es normal. Los valores sostenidos superiores a 5 indican que el host está sobreasignado en ese momento. Por tanto, todas las cifras de CPU que registre durante ese intervalo serán bajas sin que exista un problema en su máquina. top muestra la misma cifra que %st en la línea de CPU. Mantenga vmstat 1 en ejecución en una segunda sesión SSH mientras realiza las pruebas de rendimiento y anote el valor de steal junto a cada resultado.

Comience con yabs.sh

yabs.sh (Yet Another Bench Script) es un script de shell que descarga binarios estáticos de fio, iperf3 y Geekbench, los ejecuta y muestra un único resumen. Es la referencia común en las conversaciones sobre benchmarks de VPS, por lo que una salida de yabs es la forma más rápida de comparar resultados con otra persona.

El formato de una sola línea del propio proyecto es el siguiente.

curl -sL yabs.sh | bash

Ese comando envía directamente a un shell todo lo que la URL sirva en ese momento. Descárguelo, léalo y ejecútelo después.

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

Las opciones van después de -s -- cuando se usa una tubería, o directamente después del nombre de archivo cuando se ejecuta una copia local. Las más útiles son: -f omite la prueba de disco, -i omite la prueba de red, -g omite Geekbench, -r reduce a dos las ubicaciones de iperf3, -j muestra los resultados en JSON y -w results.json escribe ese JSON en un archivo.

bash yabs.sh -r -w yabs-run1.json

Debe conocer dos aspectos antes de la primera ejecución. Geekbench carga el resultado y muestra una URL pública de browser.geekbench.com, por lo que cualquiera que tenga ese enlace puede consultar el modelo de CPU y las puntuaciones. -g omite completamente esa prueba. Además, la fase de iperf3 genera tráfico real hacia servidores de varias regiones, y ese tráfico se descuenta del límite mensual de ancho de banda. En un enlace de 1 Gbit/s, una fase de red completa puede transferir decenas de gigabytes. Use -r si el límite es bajo y -i si el tráfico se factura por consumo.

Qué significa cada parte de la salida de yabs

La sección de disco ejecuta fio con una combinación de lectura y escritura al 50/50 en cuatro tamaños de bloque: 4k, 64k, 512k y 1m. Informa de los IOPS (operaciones de entrada/salida por segundo) y del ancho de banda para cada tamaño. La fila de 4k es la importante para una base de datos, un servidor de correo o cualquier sistema que realice muchas escrituras pequeñas, porque la mayoría de las operaciones de E/S del servidor son pequeñas y dispersas. La fila de 1m corresponde a copias de seguridad y vídeo, donde se mueven secuencias largas de bytes.

La sección de red ejecuta iperf3 contra servidores públicos de varias regiones, en ambas direcciones y mediante flujos paralelos. Considere un valor bajo como una pregunta, no como una conclusión, porque los servidores públicos de iperf3 son compartidos y suelen estar saturados. Por tanto, un resultado bajo puede deberse al extremo remoto.

La sección de Geekbench proporciona una puntuación de un solo núcleo y otra de varios núcleos. La puntuación de un solo núcleo permite estimar la rapidez con la que termina una petición, una compilación o una consulta. La puntuación de varios núcleos indica principalmente cuántos núcleos recibió realmente.

Disco: ejecutar fio directamente

fio (flexible IO tester) es la herramienta que usa la sección de disco de yabs. Ejecutarla directamente permite entender qué hace cada opción.

sudo apt update && sudo apt install -y fio sysbench iperf3

Una prueba de lectura aleatoria de 4k, con una profundidad de cola de 32 y en el sistema de archivos que realmente le interesa:

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

La línea de resumen que debe buscar en la salida tiene este formato.

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

Debajo, fio muestra un bloque clat percentiles. El percentil 99.00 es la cifra más útil para informar, porque indica cuánto esperó la solicitud más lenta de cada cien. La latencia media oculta precisamente las pausas que nota el usuario.

• --direct=1 abre el archivo con O_DIRECT, por lo que las lecturas omiten la caché de páginas del kernel. Sin esta opción, la segunda pasada sobre un archivo de 2G en una máquina con 8G de RAM se sirve desde la memoria y fio informa de millones de IOPS. Esa cifra es real, pero corresponde a la memoria.
• --ioengine=libaio envía solicitudes asíncronas. Esto permite que --iodepth=32 mantenga 32 solicitudes en curso. Con un motor síncrono como psync, una profundidad de E/S superior a 1 no hace nada, por lo que se mide una solicitud cada vez.
• --time_based --runtime=60 ejecuta la prueba durante 60 segundos fijos en lugar de procesar una cantidad fija de trabajo. Así, un disco rápido y uno lento usan el mismo tiempo real y la comparación sigue siendo válida.
• --size=2G establece el tamaño del archivo de prueba. Manténgalo mayor que cualquier caché de la ruta y compruebe antes que haya espacio libre suficiente.

La escritura aleatoria usa el mismo comando con --rw=randwrite. Ejecútela por separado y elimine después el archivo.

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

Para una combinación más cercana al tráfico real, use --rw=randrw --rwmixread=70. La clase de almacenamiento utilizada influye en estos resultados más que cualquier opción. Esta diferencia se explica en la diferencia entre el almacenamiento SSD NVMe y SATA en un VPS.

Cuando fio se detiene con Unknown error -1

La E/S directa no está disponible en todos los sistemas de archivos. overlay, el sistema de archivos que Docker proporciona a un contenedor de forma predeterminada, y varios sistemas de archivos de red no admiten O_DIRECT. Por eso, libaio envía una solicitud que el kernel no puede completar y fio abandona la ejecución:

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

Ejecute primero df -hT .. Si la columna Type muestra overlay, indique en --filename una ruta de almacenamiento real, como un volumen montado mediante bind, o ejecute fio en el host en lugar de hacerlo dentro del contenedor. Si no puede acceder a un almacenamiento real, una ejecución síncrona con búferes al menos confirma que el comando es correcto.

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

Sea claro sobre lo que representa esa ejecución. Después de la primera pasada, el archivo de 256M permanece en la caché de páginas, por lo que la cifra de IOPS describe la RAM. Utilícela para confirmar que fio está instalado y que los flags se interpretan correctamente. Nunca la presente como un resultado del disco.

Por qué dd no es una prueba de rendimiento del disco

dd aparece en muchos hilos sobre VPS y responde a una pregunta concreta.

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

Mide el rendimiento de escritura secuencial con un hilo y una solicitud en curso. Es una comprobación básica razonable. No dice nada sobre la E/S aleatoria ni sobre lo que ocurre cuando llegan 32 solicitudes a la vez. Si se omite oflag=direct, mide principalmente la rapidez con la que el kernel acepta las escrituras en memoria. Por eso, las cifras de dd citadas en las publicaciones de los foros suelen ser absurdas.

CPU: sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

La cifra que debe conservar es events per second. Ejecute primero la prueba con un solo hilo. Ese valor determina la rapidez con la que termina una petición PHP o un trabajo de compilación, y es el que más varía entre hosts con el mismo precio. Después, ejecútela con todos los hilos. Así podrá comprobar si sus vCPU son núcleos independientes o partes de un mismo núcleo.

Tenga claro qué mide esta prueba: sysbench busca repetidamente números primos mediante aritmética entera de 64 bits. No somete el ancho de banda de memoria, las unidades vectoriales ni la caché a una carga que se parezca a una carga real. Por tanto, sirve para comparar dos hosts, pero no para predecir cómo se ejecutará su aplicación.

Ubuntu 24.04 incluye sysbench 1.0.20, donde el nombre de la prueba aparece primero. Si copia de una publicación antigua un comando con --test=cpu, obtendrá WARNING: the --test option is deprecated. Las puntuaciones de sysbench 0.4 y sysbench 1.0 no son comparables. No se compare nunca con una cifra publicada que no indique su versión.

Memoria: sysbench memory

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

El resultado se expresa en MiB/sec, y las lecturas son más rápidas que las escrituras en todas las máquinas. Mantenga --memory-block-size en 1M y déjelo idéntico en todos los hosts que compare. Con 1K, el número se desploma porque el coste por operación se aplica mil veces más a menudo. Por tanto, termina midiendo el coste del bucle en lugar del ancho de banda de la memoria. Esta es la opción que más suele diferir entre las puntuaciones de memoria publicadas.

Red: iperf3

La forma correcta de probar el rendimiento es hacerlo contra un segundo equipo que controle, porque así sabe qué está haciendo cada extremo.

En el extremo remoto:

iperf3 -s

El servicio escucha en TCP 5201. Abra el puerto sólo para la dirección desde la que hará la prueba y ciérrelo al terminar. Reglas básicas del firewall ufw en un VPS explica la sintaxis.

Desde el VPS que está probando:

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

El primer comando mide la velocidad de subida desde el equipo probado. -R invierte la dirección y mide la velocidad de descarga. -P 8 abre ocho flujos paralelos.

Ejecute tanto el flujo único como la versión paralela, porque responden a preguntas distintas. Una conexión TCP sólo puede mantener tantos datos sin confirmar como permite su ventana, por lo que su límite es aproximadamente el tamaño de la ventana dividido por el tiempo de ida y vuelta. Con una latencia de 80 ms y una ventana de 4 MB, ese límite es de unos 400 Mbit/s, por rápida que sea la conexión subyacente. El resultado del flujo único indica qué velocidad obtendrá una descarga individual. El resultado paralelo indica la capacidad de la conexión.

Vigile el límite de ancho de banda mientras hace estas pruebas. Treinta segundos a 1 Gbit/s transfieren unos 3.75 GB, y ejecutará la prueba varias veces en cada dirección.

Cifras de referencia y cómo interpretar las suyas

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

Un volumen NVMe local suele alcanzar cerca de 180,000 IOPS de lectura aleatoria de 4k en los resultados publicados. Un SSD SATA local se sitúa alrededor de 90,000. El almacenamiento de bloques conectado por red, donde cada solicitud atraviesa la red antes de llegar al disco, se acerca más a 12,000, y un disco mecánico alcanza aproximadamente 180, porque mueve un cabezal físico para cada solicitud aleatoria.

Estas son cifras publicadas habituales para cada clase de almacenamiento, no mediciones de un único host. Úselas para un solo propósito: comprobar que su propio resultado está en el mismo orden de magnitud. Si un plan anunciado como NVMe obtiene pocos miles de IOPS de lectura aleatoria de 4k en la prueba, confirme primero que --direct=1 estaba activado. Si lo estaba, entonces el almacenamiento no es el que describe la página del producto o lo comparte con un vecino que genera mucha carga.

Por qué una ejecución no es una prueba comparativa

Un solo resultado es una instantánea de un minuto en una máquina compartida. Trátelo como una muestra.

• Ejecute cada prueba al menos cinco veces, distribuidas en distintas horas y en al menos dos días diferentes. Conserve la mediana y la dispersión. Un resultado publicado sin dispersión es una cifra de marketing.
• Registre el tiempo de steal junto a cada ejecución. Descarte las ejecuciones en las que st haya sido alto o, como mínimo, indíquelo.
• Ejecute la prueba de disco con dos duraciones. Muchos planes proporcionan una asignación de IOPS en ráfaga que se repone con el tiempo, por lo que una ejecución de fio de 60 segundos mide la ráfaga, mientras que --runtime=600 mide el rendimiento mínimo. El rendimiento mínimo es el que obtiene en un día desfavorable.
• Compruebe que no haya ningún otro proceso en ejecución. unattended-upgrades iniciar una transacción de apt en mitad de una prueba de CPU le resta puntos reales, y ps -e -o comm= | grep -E 'apt|dpkg' antes de cada ejecución sólo tarda un segundo.
• Cambie una sola variable cada vez. Las distintas versiones de las herramientas, los tamaños de bloque o los recuentos de subprocesos producen cifras que no se pueden comparar, por similares que parezcan.

Cuando compare dos proveedores, ejecute las pruebas a la misma hora del mismo día. De lo contrario, habrá medido la hora del día.

Compare primero tu propia carga de trabajo

Las herramientas sintéticas clasifican las máquinas. Sólo tu propia carga de trabajo indica si una máquina es suficiente. Mide el tiempo de la tarea que realmente realizas.

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

Esto comprime unos cientos de megabytes, por lo que utiliza la CPU y el disco a la vez y cambia cuando cambia cualquiera de los dos. La advertencia de Removing leading / from member names es normal. Mejor aún, mide el tiempo de tu propia compilación, de tu consulta más lenta o de tu propia renderización de páginas. Una compilación que tarda 4 minutos en un host y 7 en otro resuelve la cuestión, independientemente de lo que haya indicado Geekbench. Esta es también la medición que indica cuándo deja de compensar pagar por una máquina más potente. Conviene saberlo antes de leer cuánto cuesta realmente un VPS al mes o trasladar la carga de trabajo a un servidor dedicado.

FAQ

¿Por qué obtengo un resultado diferente cada vez que ejecuto la prueba?

Un VPS comparte la CPU física, el almacenamiento y la red con otros usuarios, por lo que el resultado depende de lo que hagan en ese momento. Ejecute vmstat 1 durante la prueba y lea la columna st: un tiempo de steal sostenido superior a 5 indica que el host estaba ocupado y que la puntuación de CPU es baja por motivos ajenos a su máquina. La solución es aplicar un método, no ajustar parámetros. Ejecute cada prueba cinco veces o más durante distintas horas y, después, informe de la mediana junto con la dispersión.

¿Por qué fio informa de millones de IOPS?

Casi siempre se debe a que falta --direct=1. Sin esta opción, fio lee mediante la caché de páginas del kernel. Después de la primera pasada, el archivo de prueba de 2G se sirve desde la RAM y lo que ha medido es el ancho de banda de la memoria. Añada --direct=1 y mantenga el archivo de prueba por encima del tamaño de cualquier caché de la ruta. Si --direct=1 falla entonces con err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, ejecute df -hT .: un Type de overlay no admite O_DIRECT, por lo que debe dirigir la prueba al almacenamiento real.

¿Es suficiente yabs.sh por sí solo?

Para una primera revisión, sí. Ejecuta fio con cuatro tamaños de bloque, iperf3 en ambas direcciones y Geekbench, y muestra un resumen que otras personas pueden leer. Deja de ser suficiente cuando necesita saber por qué un número tiene ese valor, porque no puede variar sus flags para cada prueba. Cuando un resultado de yabs parece incorrecto, reprodúzcalo directamente con fio o sysbench y cambie un flag cada vez.

¿Qué único número predice cómo responderá mi aplicación?

La velocidad de la CPU en un solo núcleo y la latencia de lectura aleatoria 4k, en ese orden, para la mayoría de las cargas de trabajo web y de bases de datos. Las cifras de rendimiento parecen impresionantes y rara vez determinan algo, porque una petición típica es pequeña. Informe del percentil 99 del bloque clat percentiles de fio en lugar del promedio, ya que la petición lenta de cada cien es la que nota el usuario.

¿Necesito instalar algo antes de realizar las pruebas?

fio, sysbench e iperf3 están disponibles en los repositorios de Ubuntu y Debian: sudo apt install -y fio sysbench iperf3. yabs.sh sólo necesita curl, porque descarga binarios estáticos para todo lo que falte. Elimine todos los archivos de prueba al terminar, ya que un archivo de fio de 2G abandonado en un disco de 20G se convertirá en la alerta de disco lleno de alguien varias semanas después.