¿Qué es SysBench? Si trabaja con MySQL de forma regular, lo más probable es que haya oído hablar de él. SysBench ha estado en el ecosistema MySQL durante mucho tiempo. Fue escrito originalmente por Peter Zaitsev, en 2004. Su propósito era proporcionar una herramienta para ejecutar pruebas comparativas sintéticas de MySQL y el hardware en el que se ejecuta. Fue diseñado para ejecutar pruebas de CPU, memoria y E/S. También tenía una opción para ejecutar la carga de trabajo OLTP en una base de datos MySQL. OLTP significa procesamiento de transacciones en línea, carga de trabajo típica para aplicaciones en línea como comercio electrónico, entrada de pedidos o sistemas de transacciones financieras.
En esta publicación de blog, nos centraremos en la función de evaluación comparativa de SQL, pero tenga en cuenta que las evaluaciones comparativas de hardware también pueden ser muy útiles para identificar problemas en los servidores de bases de datos. Por ejemplo, el punto de referencia de E/S tenía la intención de simular la carga de trabajo de E/S de InnoDB, mientras que las pruebas de CPU implican la simulación de un entorno multiproceso altamente concurrente junto con pruebas de contenciones de exclusión mutua, algo que también se asemeja a una carga de trabajo de tipo base de datos.
Historia y arquitectura de SysBench
Como se mencionó, SysBench fue creado originalmente en 2004 por Peter Zaitsev. Poco después, Alexey Kopytov se hizo cargo de su desarrollo. Llegó a la versión 0.4.12 y el desarrollo se detuvo. Después de un largo descanso, Alexey comenzó a trabajar en SysBench nuevamente en 2016. Pronto se lanzó la versión 0.5 con el punto de referencia OLTP reescrito para usar scripts basados en LUA. Luego, en 2017, se lanzó SysBench 1.0. Esto era como el día y la noche en comparación con la versión anterior 0.4.12. En primer lugar, en lugar de scripts codificados, ahora tenemos la capacidad de personalizar los puntos de referencia mediante LUA. Por ejemplo, Percona creó un punto de referencia similar a TPCC que se puede ejecutar usando SysBench. Echemos un vistazo rápido a la arquitectura actual de SysBench.
SysBench es un binario C que utiliza scripts LUA para ejecutar puntos de referencia. Esos scripts tienen que:
- Manejar la entrada desde los parámetros de la línea de comando
- Defina todos los modos que se supone que debe usar el punto de referencia (preparar, ejecutar, limpiar)
- Preparar todos los datos
- Defina cómo se ejecutará el punto de referencia (cómo se verán las consultas, etc.)
Los scripts pueden utilizar múltiples conexiones a la base de datos, también pueden procesar resultados si desea crear puntos de referencia complejos donde las consultas dependen del conjunto de resultados de consultas anteriores. Con SysBench 1.0 es posible crear histogramas de latencia. También es posible que los scripts LUA detecten y manejen errores a través de ganchos de error. Hay soporte para la paralelización en los scripts LUA, se pueden ejecutar múltiples consultas en paralelo, lo que hace, por ejemplo, que el aprovisionamiento sea mucho más rápido. Por último, pero no menos importante, ahora se admiten múltiples formatos de salida. Antes, SysBench generaba solo resultados legibles por humanos. Ahora es posible generarlo como CSV o JSON, lo que facilita mucho el posprocesamiento y la generación de gráficos utilizando, por ejemplo, gnuplot o alimentar los datos en Prometheus, Graphite o un almacén de datos similar.
¿Por qué SysBench?
La razón principal por la que SysBench se hizo popular es el hecho de que es fácil de usar. Alguien sin conocimientos previos puede empezar a usarlo en cuestión de minutos. También proporciona, de forma predeterminada, puntos de referencia que cubren la mayoría de los casos:cargas de trabajo OLTP, solo lectura o lectura y escritura, búsquedas de clave principal y actualizaciones de clave principal. Todo lo cual causó la mayoría de los problemas de MySQL, hasta MySQL 8.0. Esta también fue una de las razones por las que SysBench fue tan popular en diferentes puntos de referencia y comparaciones publicadas en Internet. Esas publicaciones ayudaron a promocionar esta herramienta y la convirtieron en el punto de referencia sintético para MySQL.
Otra cosa buena de SysBench es que, desde la versión 0.5 y la incorporación de LUA, cualquiera puede preparar cualquier tipo de benchmark. Ya mencionamos un punto de referencia similar al TPCC, pero cualquiera puede crear algo que se asemeje a su carga de trabajo de producción. No decimos que sea simple, lo más probable es que sea un proceso que lleve mucho tiempo, pero tener esta capacidad es beneficioso si necesita preparar un punto de referencia personalizado.
Al ser un punto de referencia sintético, SysBench no es una herramienta que pueda usar para ajustar las configuraciones de sus servidores MySQL (a menos que haya preparado scripts LUA con una carga de trabajo personalizada o que su carga de trabajo sea muy similar a las cargas de trabajo de referencia que viene con SysBench). Para lo que es genial es para comparar el rendimiento de diferentes hardware. Puede comparar fácilmente el rendimiento de, digamos, diferentes tipos de nodos ofrecidos por su proveedor de la nube y el máximo de QPS (consultas por segundo) que ofrecen. Conociendo esa métrica y sabiendo lo que paga por un nodo determinado, puede calcular una métrica aún más importante:QP$ (consultas por dólar). Esto le permitirá identificar qué tipo de nodo usar al crear un entorno rentable. Por supuesto, SysBench también se puede utilizar para el ajuste inicial y la evaluación de la viabilidad de un diseño determinado. Digamos que construimos un clúster de Galera que se extiende por todo el mundo:América del Norte, la UE, Asia. ¿Cuántas inserciones por segundo puede manejar una configuración de este tipo? ¿Cuál sería la latencia de confirmación? ¿Tiene sentido hacer una prueba de concepto o tal vez la latencia de la red es lo suficientemente alta como para que incluso una carga de trabajo simple no funcione como se esperaría?
¿Qué pasa con las pruebas de estrés? No todos se han mudado a la nube, todavía hay empresas que prefieren construir su propia infraestructura. Cada nuevo servidor adquirido debe pasar por un período de calentamiento durante el cual lo estresará para identificar posibles defectos de hardware. En este caso SysBench también puede ayudar. Ya sea mediante la ejecución de la carga de trabajo OLTP que sobrecarga el servidor, o también puede usar puntos de referencia dedicados para la CPU, el disco y la memoria.
Como puede ver, hay muchos casos en los que incluso un benchmark simple y sintético puede ser muy útil. En el siguiente párrafo veremos lo que podemos hacer con SysBench.
¿Qué puede hacer SysBench por usted?
¿Qué pruebas puede ejecutar?
Como se mencionó al principio, nos centraremos en los puntos de referencia de OLTP y, como recordatorio, repetiremos que SysBench también se puede usar para realizar pruebas de E/S, CPU y memoria. Echemos un vistazo a los puntos de referencia que viene con SysBench 1.0 (eliminamos algunos archivos LUA auxiliares y scripts LUA que no son de base de datos de esta lista).
-rwxr-xr-x 1 root root 1.5K May 30 07:46 bulk_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_delete.lua
-rwxr-xr-x 1 root root 2.4K May 30 07:46 oltp_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_point_select.lua
-rwxr-xr-x 1 root root 1.7K May 30 07:46 oltp_read_only.lua
-rwxr-xr-x 1 root root 1.8K May 30 07:46 oltp_read_write.lua
-rwxr-xr-x 1 root root 1.1K May 30 07:46 oltp_update_index.lua
-rwxr-xr-x 1 root root 1.2K May 30 07:46 oltp_update_non_index.lua
-rwxr-xr-x 1 root root 1.5K May 30 07:46 oltp_write_only.lua
-rwxr-xr-x 1 root root 1.9K May 30 07:46 select_random_points.lua
-rwxr-xr-x 1 root root 2.1K May 30 07:46 select_random_ranges.luaRepasémoslos uno por uno.
Primero, bulk_insert.lua. Esta prueba se puede utilizar para comparar la capacidad de MySQL para realizar inserciones de varias filas. Esto puede ser bastante útil al verificar, por ejemplo, el rendimiento de la replicación o el clúster de Galera. En el primer caso, puede ayudarlo a responder una pregunta:"¿qué tan rápido puedo insertar antes de que se active el retraso de la replicación?". En el último caso, le indicará qué tan rápido se pueden insertar los datos en un clúster de Galera dada la latencia actual de la red.
Todos los scripts oltp_* comparten una estructura de tabla común. Los dos primeros (oltp_delete.lua y oltp_insert.lua) ejecutan instrucciones DELETE e INSERT individuales. Nuevamente, esto podría ser una prueba para la replicación o el clúster de Galera:llévelo al límite y vea qué cantidad de inserción o purga puede manejar. También tenemos otros puntos de referencia centrados en una funcionalidad particular:oltp_point_select, oltp_update_index y oltp_update_non_index. Estos ejecutarán un subconjunto de consultas:selecciones basadas en claves principales, actualizaciones basadas en índices y actualizaciones no basadas en índices. Si quieres probar algunas de estas funcionalidades, las pruebas están ahí. También tenemos puntos de referencia más complejos que se basan en cargas de trabajo OLTP:oltp_read_only, oltp_read_write y oltp_write_only. Puede ejecutar una carga de trabajo de solo lectura, que consistirá en diferentes tipos de consultas SELECT, puede ejecutar solo escrituras (una combinación de ELIMINAR, INSERTAR y ACTUALIZAR) o puede ejecutar una combinación de esos dos. Finalmente, usando select_random_points y select_random_ranges puede ejecutar algunos SELECT aleatorios usando puntos aleatorios en la lista IN() o rangos aleatorios usando BETWEEN.
¿Cómo se puede configurar un Benchmark?
Lo que también es importante, los puntos de referencia son configurables:puede ejecutar diferentes patrones de carga de trabajo utilizando el mismo punto de referencia. Echemos un vistazo a los dos puntos de referencia más comunes para ejecutar. Profundizaremos en los puntos de referencia de OLTP read_only y OLTP read_write. En primer lugar, SysBench tiene algunas opciones de configuración generales. Discutiremos aquí solo los más importantes, puede verificarlos todos ejecutando:
sysbench --helpEchemos un vistazo a ellos.
--threads=N number of threads to use [1]Puede definir qué tipo de concurrencia desea que genere SysBench. MySQL, como todo software, tiene algunas limitaciones de escalabilidad y su rendimiento alcanzará su punto máximo en algún nivel de concurrencia. Esta configuración ayuda a simular diferentes simultaneidades para una carga de trabajo determinada y verificar si ya pasó el punto ideal.
--events=N limit for total number of events [0]
--time=N limit for total execution time in seconds [10]Esas dos configuraciones gobiernan cuánto tiempo debe seguir funcionando SysBench. Puede ejecutar una cierta cantidad de consultas o puede seguir ejecutándose durante un tiempo predefinido.
--warmup-time=N execute events for this many seconds with statistics disabled before the actual benchmark run with statistics enabled [0]Esto se explica por sí mismo. SysBench genera resultados estadísticos de las pruebas y esos resultados pueden verse afectados si MySQL está en un estado frío. El calentamiento ayuda a identificar el rendimiento "regular" al ejecutar el punto de referencia durante un tiempo predefinido, lo que permite calentar la memoria caché, los grupos de búfer, etc.
--rate=N average transactions rate. 0 for unlimited rate [0]Por defecto, SysBench intentará ejecutar consultas lo más rápido posible. Para simular un tráfico más lento, se puede utilizar esta opción. Puede definir aquí cuántas transacciones deben ejecutarse por segundo.
--report-interval=N periodically report intermediate statistics with a specified interval in seconds. 0 disables intermediate reports [0]De forma predeterminada, SysBench genera un informe después de completar su ejecución y no se informa ningún progreso mientras se ejecuta el punto de referencia. Con esta opción, puede hacer que SysBench sea más detallado mientras el punto de referencia aún se ejecuta.
--rand-type=STRING random numbers distribution {uniform, gaussian, special, pareto, zipfian} to use by default [special]SysBench le brinda la capacidad de generar diferentes tipos de distribución de datos. Todos ellos pueden tener sus propios fines. La opción por defecto, 'especial', define varios (es configurable) puntos calientes en los datos, algo que es bastante común en las aplicaciones web. También puede usar otras distribuciones si sus datos se comportan de manera diferente. Al hacer una elección diferente aquí, también puede cambiar la forma en que se estresa su base de datos. Por ejemplo, la distribución uniforme, donde todas las filas tienen la misma probabilidad de ser accedidas, es una operación que requiere mucha más memoria. Utilizará más grupo de búfer para almacenar todos los datos y será mucho más intensivo en disco si su conjunto de datos no cabe en la memoria. Por otro lado, la distribución especial con un par de zonas activas ejercerá menos presión sobre el disco, ya que es más probable que las filas activas se mantengan en el grupo de búfer y el acceso a las filas almacenadas en el disco es mucho menos probable. Para algunos de los tipos de distribución de datos, SysBench le brinda más ajustes. Puede encontrar esta información en la salida 'sysbench --help'.
--db-ps-mode=STRING prepared statements usage mode {auto, disable} [auto]Con esta configuración, puede decidir si SysBench debe usar declaraciones preparadas (siempre que estén disponibles en el almacén de datos dado; para MySQL, significa que PS estará habilitado de manera predeterminada) o no. Esto puede marcar la diferencia al trabajar con proxies como ProxySQL o MaxScale:deben tratar las declaraciones preparadas de una manera especial y todas deben enrutarse a un host, lo que hace imposible probar la escalabilidad del proxy.
Además de las opciones generales de configuración, cada una de las pruebas puede tener su propia configuración. Puede verificar lo que es posible ejecutando:
[email protected]:~# sysbench ./sysbench/src/lua/oltp_read_write.lua help
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)
oltp_read_only.lua options:
--distinct_ranges=N Number of SELECT DISTINCT queries per transaction [1]
--sum_ranges=N Number of SELECT SUM() queries per transaction [1]
--skip_trx[=on|off] Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]
--secondary[=on|off] Use a secondary index in place of the PRIMARY KEY [off]
--create_secondary[=on|off] Create a secondary index in addition to the PRIMARY KEY [on]
--index_updates=N Number of UPDATE index queries per transaction [1]
--range_size=N Range size for range SELECT queries [100]
--auto_inc[=on|off] Use AUTO_INCREMENT column as Primary Key (for MySQL), or its alternatives in other DBMS. When disabled, use client-generated IDs [on]
--delete_inserts=N Number of DELETE/INSERT combinations per transaction [1]
--tables=N Number of tables [1]
--mysql_storage_engine=STRING Storage engine, if MySQL is used [innodb]
--non_index_updates=N Number of UPDATE non-index queries per transaction [1]
--table_size=N Number of rows per table [10000]
--pgsql_variant=STRING Use this PostgreSQL variant when running with the PostgreSQL driver. The only currently supported variant is 'redshift'. When enabled, create_secondary is automatically disabled, and delete_inserts is set to 0
--simple_ranges=N Number of simple range SELECT queries per transaction [1]
--order_ranges=N Number of SELECT ORDER BY queries per transaction [1]
--range_selects[=on|off] Enable/disable all range SELECT queries [on]
--point_selects=N Number of point SELECT queries per transaction [10]Nuevamente, discutiremos las opciones más importantes desde aquí. En primer lugar, tiene un control de cómo se verá exactamente una transacción. En términos generales, consta de diferentes tipos de consultas:INSERTAR, ELIMINAR, diferentes tipos de SELECCIÓN (búsqueda de puntos, rango, agregación) y ACTUALIZAR (indexada, no indexada). Usando variables como:
--distinct_ranges=N Number of SELECT DISTINCT queries per transaction [1]
--sum_ranges=N Number of SELECT SUM() queries per transaction [1]
--index_updates=N Number of UPDATE index queries per transaction [1]
--delete_inserts=N Number of DELETE/INSERT combinations per transaction [1]
--non_index_updates=N Number of UPDATE non-index queries per transaction [1]
--simple_ranges=N Number of simple range SELECT queries per transaction [1]
--order_ranges=N Number of SELECT ORDER BY queries per transaction [1]
--point_selects=N Number of point SELECT queries per transaction [10]
--range_selects[=on|off] Enable/disable all range SELECT queries [on]Puede definir el aspecto que debe tener una transacción. Como puede ver al observar los valores predeterminados, la mayoría de las consultas son SELECCIONES, principalmente selecciones de puntos, pero también diferentes tipos de SELECCIONES de rango (puede deshabilitarlas todas desactivando range_selects). Puede ajustar la carga de trabajo hacia una carga de trabajo más intensiva en escritura aumentando la cantidad de actualizaciones o INSERTAR/ELIMINAR consultas. También es posible modificar la configuración relacionada con los índices secundarios, el incremento automático, pero también el tamaño del conjunto de datos (número de tablas y cuántas filas debe contener cada una de ellas). Esto le permite personalizar su carga de trabajo muy bien.
--skip_trx[=on|off] Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]Esta es otra configuración, bastante importante cuando se trabaja con proxies. De forma predeterminada, SysBench intentará ejecutar consultas en transacciones explícitas. De esta manera, el conjunto de datos se mantendrá consistente y no se verá afectado:SysBench, por ejemplo, ejecutará INSERTAR y ELIMINAR en la misma fila, asegurándose de que el conjunto de datos no crezca (lo que afectará su capacidad para reproducir resultados). Sin embargo, los servidores proxy tratarán las transacciones explícitas de manera diferente:todas las consultas ejecutadas dentro de una transacción deben ejecutarse en el mismo host, lo que elimina la capacidad de escalar la carga de trabajo. Tenga en cuenta que deshabilitar las transacciones dará como resultado que el conjunto de datos difiera del punto inicial. También puede desencadenar algunos problemas como errores de clave duplicada o similares. Para poder deshabilitar las transacciones, también puede consultar:
--mysql-ignore-errors=[LIST,...] list of errors to ignore, or "all" [1213,1020,1205]Esta configuración le permite especificar códigos de error de MySQL que SysBench debe ignorar (y no eliminar la conexión). Por ejemplo, para ignorar errores como:error 1062 (entrada duplicada '6' para la clave 'PRIMARY') debe pasar este código de error:--mysql-ignore-errors=1062
Lo que también es importante, cada punto de referencia debe presentar una forma de aprovisionar un conjunto de datos para las pruebas, ejecutarlas y luego limpiarlas después de que se completen las pruebas. Esto se hace usando los comandos 'preparar', 'ejecutar' y 'limpiar'. Mostraremos cómo se hace esto en la siguiente sección.
Ejemplos
En esta sección, veremos algunos ejemplos de para qué se puede usar SysBench. Como se mencionó anteriormente, nos centraremos en los dos puntos de referencia más populares:solo lectura OLTP y lectura/escritura OLTP. A veces puede tener sentido usar otros puntos de referencia, pero al menos podremos mostrarle cómo se pueden personalizar esos dos.
Búsquedas de clave principal
En primer lugar, tenemos que decidir qué punto de referencia ejecutaremos, solo lectura o lectura y escritura. Técnicamente hablando, no hace ninguna diferencia, ya que podemos eliminar las escrituras del punto de referencia R/W. Centrémonos en el de solo lectura.
Como primer paso, tenemos que preparar un conjunto de datos. Tenemos que decidir qué tan grande debe ser. Para este punto de referencia en particular, usando la configuración predeterminada (por lo tanto, se crean índices secundarios), 1 millón de filas darán como resultado ~240 MB de datos. Diez tablas, 1000 000 filas cada una equivale a 2,4 GB:
[email protected]:~# du -sh /var/lib/mysql/sbtest/
2.4G /var/lib/mysql/sbtest/
[email protected]:~# ls -alh /var/lib/mysql/sbtest/
total 2.4G
drwxr-x--- 2 mysql mysql 4.0K Jun 1 12:12 .
drwxr-xr-x 6 mysql mysql 4.0K Jun 1 12:10 ..
-rw-r----- 1 mysql mysql 65 Jun 1 12:08 db.opt
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:12 sbtest10.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:12 sbtest10.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest1.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest1.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest2.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest2.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest3.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest3.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest4.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest4.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest5.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest5.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest6.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest6.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest7.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest7.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest8.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest8.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:12 sbtest9.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:12 sbtest9.ibdEsto debería darle una idea de cuántas mesas quiere y qué tan grandes deberían ser. Digamos que queremos probar la carga de trabajo en memoria, por lo que queremos crear tablas que se ajusten al grupo de búfer de InnoDB. Por otro lado, también queremos asegurarnos de que haya suficientes mesas para no convertirse en un cuello de botella (o que la cantidad de mesas coincida con lo que esperaría en su configuración de producción). Preparemos nuestro conjunto de datos. Tenga en cuenta que, de forma predeterminada, SysBench busca el esquema 'sbtest' que debe existir antes de preparar el conjunto de datos. Puede que tenga que crearlo manualmente.
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 prepare
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)
Initializing worker threads...
Creating table 'sbtest2'...
Creating table 'sbtest3'...
Creating table 'sbtest4'...
Creating table 'sbtest1'...
Inserting 1000000 records into 'sbtest2'
Inserting 1000000 records into 'sbtest4'
Inserting 1000000 records into 'sbtest3'
Inserting 1000000 records into 'sbtest1'
Creating a secondary index on 'sbtest2'...
Creating a secondary index on 'sbtest3'...
Creating a secondary index on 'sbtest1'...
Creating a secondary index on 'sbtest4'...
Creating table 'sbtest6'...
Inserting 1000000 records into 'sbtest6'
Creating table 'sbtest7'...
Inserting 1000000 records into 'sbtest7'
Creating table 'sbtest5'...
Inserting 1000000 records into 'sbtest5'
Creating table 'sbtest8'...
Inserting 1000000 records into 'sbtest8'
Creating a secondary index on 'sbtest6'...
Creating a secondary index on 'sbtest7'...
Creating a secondary index on 'sbtest5'...
Creating a secondary index on 'sbtest8'...
Creating table 'sbtest10'...
Inserting 1000000 records into 'sbtest10'
Creating table 'sbtest9'...
Inserting 1000000 records into 'sbtest9'
Creating a secondary index on 'sbtest10'...
Creating a secondary index on 'sbtest9'...Una vez que tengamos nuestros datos, preparemos un comando para ejecutar la prueba. Queremos probar las búsquedas de clave principal, por lo tanto, deshabilitaremos todos los demás tipos de SELECT. También deshabilitaremos las declaraciones preparadas ya que queremos probar consultas regulares. Probaremos baja concurrencia, digamos 16 subprocesos. Nuestro comando puede verse a continuación:
sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 run¿Qué hicimos aquí? Establecimos el número de subprocesos en 16. Decidimos que queremos que nuestro punto de referencia se ejecute durante 300 segundos, sin límite de consultas ejecutadas. Definimos conectividad a la base de datos, número de tablas y su tamaño. También deshabilitamos todos los SELECT de rango, también deshabilitamos las declaraciones preparadas. Finalmente, establecemos el intervalo de informe en un segundo. Así es como puede verse una salida de muestra:
[ 297s ] thds: 16 tps: 97.21 qps: 1127.43 (r/w/o: 935.01/0.00/192.41) lat (ms,95%): 253.35 err/s: 0.00 reconn/s: 0.00
[ 298s ] thds: 16 tps: 195.32 qps: 2378.77 (r/w/o: 1985.13/0.00/393.64) lat (ms,95%): 189.93 err/s: 0.00 reconn/s: 0.00
[ 299s ] thds: 16 tps: 178.02 qps: 2115.22 (r/w/o: 1762.18/0.00/353.04) lat (ms,95%): 155.80 err/s: 0.00 reconn/s: 0.00
[ 300s ] thds: 16 tps: 217.82 qps: 2640.92 (r/w/o: 2202.27/0.00/438.65) lat (ms,95%): 125.52 err/s: 0.00 reconn/s: 0.00Cada segundo vemos una instantánea de las estadísticas de la carga de trabajo. Esto es bastante útil para rastrear y trazar:el informe final solo le dará promedios. Los resultados intermedios permitirán realizar un seguimiento del rendimiento segundo a segundo. El informe final puede tener el siguiente aspecto:
SQL statistics:
queries performed:
read: 614660
write: 0
other: 122932
total: 737592
transactions: 61466 (204.84 per sec.)
queries: 737592 (2458.08 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
Throughput:
events/s (eps): 204.8403
time elapsed: 300.0679s
total number of events: 61466
Latency (ms):
min: 24.91
avg: 78.10
max: 331.91
95th percentile: 137.35
sum: 4800234.60
Threads fairness:
events (avg/stddev): 3841.6250/20.87
execution time (avg/stddev): 300.0147/0.02Aquí encontrará información sobre consultas ejecutadas y otras declaraciones (BEGIN/COMMIT). Aprenderá cuántas transacciones se ejecutaron, cuántos errores ocurrieron, cuál fue el rendimiento y el tiempo total transcurrido. También puede consultar las métricas de latencia y la distribución de consultas entre subprocesos.
Si estuviéramos interesados en la distribución de la latencia, también podríamos pasar el argumento '--histogram' a SysBench. Esto da como resultado una salida adicional como la siguiente:
Latency histogram (values are in milliseconds)
value ------------- distribution ------------- count
29.194 |****** 1
30.815 |****** 1
31.945 |*********** 2
33.718 |****** 1
34.954 |*********** 2
35.589 |****** 1
37.565 |*********************** 4
38.247 |****** 1
38.942 |****** 1
39.650 |*********** 2
40.370 |*********** 2
41.104 |***************** 3
41.851 |***************************** 5
42.611 |***************** 3
43.385 |***************** 3
44.173 |*********** 2
44.976 |**************************************** 7
45.793 |*********************** 4
46.625 |*********** 2
47.472 |***************************** 5
48.335 |**************************************** 7
49.213 |*********** 2
50.107 |********************************** 6
51.018 |*********************** 4
51.945 |**************************************** 7
52.889 |***************** 3
53.850 |***************** 3
54.828 |*********************** 4
55.824 |*********** 2
57.871 |*********** 2
58.923 |*********** 2
59.993 |****** 1
61.083 |****** 1
63.323 |*********** 2
66.838 |****** 1
71.830 |****** 1Una vez que estemos bien con nuestros resultados, podemos limpiar los datos:
sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 cleanupTráfico con mucho tráfico de escritura
Imaginemos aquí que queremos ejecutar una carga de trabajo de escritura intensa (pero no de solo escritura) y, por ejemplo, probar el rendimiento del subsistema de E/S. En primer lugar, tenemos que decidir qué tan grande debe ser el conjunto de datos. Asumiremos ~ 48 GB de datos (20 tablas, 10 000 000 filas cada una). Tenemos que prepararlo. Esta vez usaremos el punto de referencia de lectura y escritura.
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --table-size=10000000 prepareUna vez hecho esto, podemos modificar los valores predeterminados para forzar más escrituras en la combinación de consultas:
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --delete_inserts=10 --index_updates=10 --non_index_updates=10 --table-size=10000000 --db-ps-mode=disable --report-interval=1 runComo puede ver en los resultados intermedios, las transacciones ahora están en el lado de escritura pesada:
[ 5s ] thds: 16 tps: 16.99 qps: 946.31 (r/w/o: 231.83/680.50/33.98) lat (ms,95%): 1258.08 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 16 tps: 17.01 qps: 955.81 (r/w/o: 223.19/698.59/34.03) lat (ms,95%): 1032.01 err/s: 0.00 reconn/s: 0.00
[ 7s ] thds: 16 tps: 12.00 qps: 698.91 (r/w/o: 191.97/482.93/24.00) lat (ms,95%): 1235.62 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 16 tps: 14.01 qps: 683.43 (r/w/o: 195.12/460.29/28.02) lat (ms,95%): 1533.66 err/s: 0.00 reconn/s: 0.00Comprender los resultados
Como mostramos anteriormente, SysBench es una gran herramienta que puede ayudar a identificar algunos de los problemas de rendimiento de MySQL o MariaDB. También se puede utilizar para el ajuste inicial de la configuración de su base de datos. Por supuesto, debe tener en cuenta que, para obtener lo mejor de sus puntos de referencia, debe comprender por qué los resultados se ven así. Esto requeriría información sobre las métricas internas de MySQL utilizando herramientas de monitoreo, por ejemplo, ClusterControl. Es muy importante recordar esto:si no comprende por qué el rendimiento fue como fue, puede sacar conclusiones incorrectas de los puntos de referencia. Siempre hay un cuello de botella y SysBench puede ayudar a plantear los problemas de rendimiento, que luego debe identificar.
