loadtest.appde LoadFocus

Guías

Cómo usar sysbench: benchmarks de CPU, disco y MySQL

7 min de lectura

sysbench es una herramienta de benchmark open source y multihilo, construida sobre LuaJIT, que incluye pruebas de CPU, memoria, E/S de archivos, hilos y mutex, además de scripts OLTP para MySQL y PostgreSQL. Las pruebas que necesitan datos siguen el mismo ciclo: prepare crea los archivos o tablas de prueba, run ejecuta el benchmark durante un tiempo o un número de eventos fijo, y cleanup borra los datos; las pruebas de CPU y memoria solo necesitan run. Mide una sola máquina o un solo servidor de base de datos, así que no puede decirte cómo se comporta tu aplicación con tráfico real de usuarios.

No hemos ejecutado sysbench para esta guía. Los datos salen de su README y de su código fuente en la rama master de GitHub, comprobados el 31 de octubre de 2026, y los consejos son nuestros.

Temasysbench
LicenciaGPLv2
Escrito enC, con LuaJIT para los scripts
Última versión1.0.20 (24 de abril de 2020)
Último commit9 de marzo de 2025
Pruebas integradascpu, memory, fileio, threads, mutex
Scripts de base de datosOcho scripts oltp_*, bulk_insert, dos select_random_*
Drivers de base de datosMySQL (por defecto), PostgreSQL
PlataformasLinux, macOS; Windows mediante WSL

¿sysbench sigue teniendo mantenimiento?

Muy poco. La última versión, la 1.0.20, salió en abril de 2020; desde entonces la rama master ha recibido commits ocasionales, ninguno publicado en una versión, el último en marzo de 2025.

La versión 1.0.20 tiene fecha del 24 de abril de 2020. El historial de commits muestra cambios como una distribución uniforme por defecto para --rand-type (2020), un LuaJIT de upstream (2023) y soporte para las bibliotecas cliente de MariaDB (2023), y después cuatro commits de compilación el 9 de marzo de 2025 (comprobado el 31 de octubre de 2026). Los repositorios de paquetes del README se actualizan con cada versión, así que esos cambios requieren compilar desde el código fuente.

¿Cómo funciona una ejecución de sysbench?

Indicas una prueba y un comando: sysbench [options] [testname] [command]. La prueba es una integrada, un script Lua incluido o tu propio script, y el comando suele ser prepare, run, cleanup o help.

Según el README, prepare crea los archivos para fileio o llena la base de datos para los scripts OLTP, cleanup borra esos datos y sysbench <testname> help muestra las opciones de una prueba. Una prueba de disco:

sysbench fileio --file-total-size=8G prepare
sysbench fileio --file-total-size=8G \
  --file-test-mode=rndrw --time=300 run
sysbench fileio --file-total-size=8G cleanup

El código de fileio enumera los modos seqwr, seqrewr, seqrd, rndrd, rndwr y rndrw, con 2 GB de archivos por defecto. Los archivos que caben en memoria pueden servirse desde la caché de páginas, así que usa un tamaño mayor que la RAM si lo que quieres medir es el disco.

¿Cómo medir la CPU y la memoria con sysbench?

Con sysbench cpu run y sysbench memory run. La prueba de CPU informa de eventos por segundo, donde un evento comprueba si cada número hasta un límite es primo, y la de memoria informa de operaciones y MiB transferidos por segundo.

sysbench cpu --cpu-max-prime=20000 \
  --threads=4 --time=60 run

La prueba de CPU fija --cpu-max-prime en 10000 por defecto, y la prueba de memoria admite un tamaño de bloque, un tamaño total, operaciones de lectura o escritura y acceso secuencial o aleatorio (comprobado el 31 de octubre de 2026). Compara solo ejecuciones con la misma configuración.

¿Cómo se prueba MySQL o PostgreSQL con sysbench?

Elige uno de los scripts OLTP incluidos, llena las tablas con prepare, lanza transacciones desde varios hilos con run y luego borra las tablas con cleanup. MySQL es el driver por defecto; PostgreSQL necesita --db-driver=pgsql y una compilación con soporte para PostgreSQL.

sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 \
  --threads=16 --time=300 --report-interval=10 run

El script OLTP común crea una tabla de 10.000 filas si no pasas --tables y --table-size. En oltp_read_write, cada transacción ejecuta 10 consultas por clave, cuatro consultas por rango, dos actualizaciones y un borrado seguido de una inserción, entre BEGIN y COMMIT (comprobado el 31 de octubre de 2026). Usa más datos que el buffer pool del servidor si quieres lecturas de disco en el resultado.

¿Qué opciones de sysbench importan más?

--threads y --time fijan el tamaño y la duración de una ejecución, --rate fija una tasa objetivo de eventos, y --report-interval, --percentile y --histogram deciden lo que ves.

  • --threads: hilos de trabajo, 1 por defecto.
  • --time: segundos, 10 por defecto, 0 para no poner límite. --events limita el número de eventos, y los dos límites se aplican, así que combínalo con --time=0.
  • --warmup-time: ejecuta primero sin estadísticas, para que las cachés frías no distorsionen el resultado. Solo en master: la versión 1.0.20 no la tiene.
  • --rate: eventos medios por segundo entre todos los hilos; 0, el valor por defecto, significa lo más rápido posible.
  • --report-interval: cifras por intervalo cada N segundos, para ver los parones.
  • --percentile: el percentil de latencia que se muestra, 95 por defecto.
  • --histogram: un histograma de latencias al final, definido en sb_logger.c.

¿sysbench usa un modelo de carga cerrado o abierto?

Cerrado por defecto: un número fijo de hilos lanza cada uno el siguiente evento en cuanto termina el anterior, así que un servidor lento recibe menos eventos. Con --rate, los eventos llegan según su propio calendario, lo que se acerca más a un modelo de carga abierto.

Nuestro artículo sobre el modelo de carga abierto vs cerrado explica por qué eso cambia lo que mide un benchmark. En el modo por defecto, un parón también retrasa los eventos que habrían empezado durante ese tiempo, y esos retrasos nunca aparecen en las latencias: es la coordinated omission. El archivo fuente principal muestra que --rate encola eventos a intervalos con distribución exponencial, suma a la latencia de cada evento su espera en la cola y se detiene con el error “event queue is full” cuando los hilos no dan abasto (comprobado el 31 de octubre de 2026).

¿Cómo se lee la salida de sysbench?

Empieza por el rendimiento: eventos por segundo, o transacciones y consultas por segundo en los scripts OLTP. Después lee el bloque de latencia en milisegundos: mínimo, media, máximo, el percentil elegido (p95 por defecto) y la suma.

La versión 1.0.20 muestra, en lugar de «Throughput», un bloque «General statistics» con el tiempo total y el número total de eventos. Los nombres de campo vienen del código del informe de base de datos y del archivo fuente principal en master, aquí sin valores:

SQL statistics:
    queries performed: read, write, other, total
    transactions, queries (N per sec.)
    ignored errors, reconnects (N per sec.)
Throughput:
    events/s (eps), time elapsed, total number of events
Latency (ms):
    min, avg, max, 95th percentile, sum
Threads fairness:
    events, execution time (avg/stddev)

Un percentil 95 deja fuera el evento más lento de cada veinte. Usa --percentile=99 o añade --histogram cuando importa la cola de la distribución; nuestra guía sobre la latencia de cola explica por qué.

¿Cuándo no es sysbench la herramienta adecuada?

Cuando tu pregunta trata sobre tu aplicación. Una puntuación de CPU muestra lo rápido que una máquina comprueba números primos, y una ejecución OLTP mide el servidor de base de datos con las tablas y consultas de sysbench, sin tu esquema, tu pool de conexiones ni la ruta de red.

  • Elige pgbench para pruebas nativas de PostgreSQL: la documentación de PostgreSQL describe un escenario por defecto basado a grandes rasgos en TPC-B, además de archivos de script propios (comprobado el 31 de octubre de 2026).
  • Elige HammerDB para pruebas al estilo TPC-C: su documentación cubre la carga TPROC-C, derivada de TPC-C, para SQL Server, Db2, Oracle, PostgreSQL, MariaDB y MySQL (comprobado el 31 de octubre de 2026).
  • Elige JMeter con su sampler JDBC Request para combinar SQL y HTTP en un mismo plan de prueba; la guía de planes de prueba de base de datos indica que el .jar del driver va en la carpeta lib de JMeter.

LoadFocus, que publica este sitio, no ejecuta sysbench ni puede conectarse por sí mismo a MySQL o PostgreSQL. Ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube contra la capa web o de API que hay delante de la base de datos. Una combinación útil: una ejecución de sysbench para dimensionar el servidor de base de datos y después una prueba de carga de la aplicación para ver si las peticiones reales llegan a ese límite.

FAQ

¿sysbench sigue teniendo mantenimiento? Muy poco. La última versión es la 1.0.20, del 24 de abril de 2020. La rama master ha recibido desde entonces commits ocasionales, ninguno en una versión, el más reciente el 9 de marzo de 2025.

¿Qué significa el percentil 95 en la salida de sysbench? Es la latencia, en milisegundos, dentro de la cual terminó el 95 % de los eventos. 95 es el valor por defecto de la opción --percentile, y puedes fijar otro, como 99.

¿Puede sysbench hacer benchmarks de PostgreSQL? Sí. Los scripts OLTP incluidos funcionan contra PostgreSQL con --db-driver=pgsql cuando sysbench se ha compilado con soporte para PostgreSQL.

¿Puede LoadFocus ejecutar sysbench? No. LoadFocus ejecuta planes de prueba JMeter y scripts de k6 contra sitios web y API desde 25 regiones en la nube, y no se conecta directamente a MySQL ni a PostgreSQL.

Lecturas relacionadas

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.

LoadFocus team
Escrito por el equipo de LoadFocus, las personas detrás de un servicio de pruebas de carga en la nube.