Cómo comparar el rendimiento de PostgreSQL usando Sysbench

La evaluación comparativa es una forma de descubrir el rendimiento de su infraestructura. Sysbench es una gran herramienta para comparar servidores PostgreSQL. En esta publicación de blog, le mostraremos cómo generar cargas de prueba usando sysbench. Haremos uso de una configuración de replicación de transmisión maestro-esclavo de dos nodos por parte de ClusterControl. Esto también nos ayudará a generar algo de actividad en el clúster y verificar que la replicación funcione como se esperaba.

Instalaremos la última versión de sysbench, que actualmente se mantiene aquí. Usaremos el paquete más actualizado provisto en la página oficial de Github para instalar sysbench. También usaremos los binarios estándar de PostgreSQL 9.6 de la página de descarga de PostgreSQL. Tenga en cuenta que la ruta utilizada en esta publicación de blog puede ser diferente según la versión y el proveedor de PostgreSQL que haya instalado.

Como nota al margen, hemos cubierto una publicación de blog similar sobre la evaluación comparativa de PostgreSQL usando pgbench en esta publicación de blog, Cómo evaluar el rendimiento de PostgreSQL.

Instalación de Sysbench

Instalar sysbench es fácil. Para Debian/Ubuntu:

$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
$ sudo apt -y install sysbench

Y para RHEL/CentOS:

$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
$ sudo yum -y install sysbench

Instale el paquete sysbench:

$ yum install sysbench

Verificar la versión:

$ sysbench --version
sysbench 1.0.15

Ya hemos instalado sysbench.

Inicializar datos de prueba

Si está familiarizado con sysbench, utiliza los siguientes valores predeterminados para los parámetros de PostgreSQL:

pgsql-host=localhost
pgsql-port=5432
pgsql-user=sbtest
pgsql-password=contraseña
pgsql-db=sbtest

En primer lugar, cree la base de datos y el usuario dentro de PostgreSQL:

$ su - postgres
$ psql
> CREATE USER sbtest WITH PASSWORD 'password';
> CREATE DATABASE sbtest;
> GRANT ALL PRIVILEGES ON DATABASE sbtest TO sbtest;

Luego edite el archivo de acceso basado en host, pg_hba.conf :

$ vim /var/lib/pgsql/9.6/data/pg_hba.conf

Y agregue la siguiente línea para permitir conexiones para el usuario sbtest, a la base de datos sbtest desde todos los hosts bajo la red 192.168.55.0:

host    sbtest          sbtest          192.168.55.0/24         md5

Vuelva a cargar el servidor para aplicar los cambios:

$ /usr/pgsql-9.6/bin/pg_ctl --reload

Verifique desde el cliente de línea de comandos psql si la autenticación del usuario funciona correctamente:

$ psql -U sbtest -h 192.168.55.61 -p 5432 -d sbtest -W

Debería poder ingresar al servidor en la base de datos sbtest:

$ psql -U sbtest -h 192.168.55.61 -p 5432 -W
Password for user sbtest:
Type "help" for help.

sbtest=>

Ejecute "\q" para salir de la terminal. Ahora podemos inicializar la base de datos usando sysbench con el siguiente comando:

$ sysbench \
--db-driver=pgsql \
--oltp-table-size=100000 \
--oltp-tables-count=24 \
--threads=1 \
--pgsql-host=192.168.55.61 \
--pgsql-port=5432 \
--pgsql-user=sbtest \
--pgsql-password=password \
--pgsql-db=sbtest \
/usr/share/sysbench/tests/include/oltp_legacy/parallel_prepare.lua \
run

El comando anterior genera 100.000 filas por tabla para 24 tablas (sbtest1 a sbtest24) dentro de la base de datos 'sbtest'. El nombre del esquema es "público", que es el valor predeterminado. Los datos son preparados por un script llamado parallel_prepare.lua que está disponible en /usr/share/sysbench/tests/include/oltp_legacy.

Verifique las tablas generadas con el siguiente comando:

$ psql -U sbtest -h 192.168.55.61 -p 5432 -W -c '\dt+\'
Password for user sbtest:
                    List of relations
 Schema |   Name   | Type  | Owner  | Size  | Description
--------+----------+-------+--------+-------+-------------
 public | sbtest1  | table | sbtest | 21 MB |
 public | sbtest10 | table | sbtest | 21 MB |
 public | sbtest11 | table | sbtest | 21 MB |
 public | sbtest12 | table | sbtest | 21 MB |
 public | sbtest13 | table | sbtest | 21 MB |
 public | sbtest14 | table | sbtest | 21 MB |
 public | sbtest15 | table | sbtest | 21 MB |
 public | sbtest16 | table | sbtest | 21 MB |
 public | sbtest17 | table | sbtest | 21 MB |
 public | sbtest18 | table | sbtest | 21 MB |
 public | sbtest19 | table | sbtest | 21 MB |
 public | sbtest2  | table | sbtest | 21 MB |
 public | sbtest20 | table | sbtest | 21 MB |
 public | sbtest21 | table | sbtest | 21 MB |
 public | sbtest22 | table | sbtest | 21 MB |
 public | sbtest23 | table | sbtest | 21 MB |
 public | sbtest24 | table | sbtest | 21 MB |
 public | sbtest3  | table | sbtest | 21 MB |
 public | sbtest4  | table | sbtest | 21 MB |
 public | sbtest5  | table | sbtest | 21 MB |
 public | sbtest6  | table | sbtest | 21 MB |
 public | sbtest7  | table | sbtest | 21 MB |
 public | sbtest8  | table | sbtest | 21 MB |
 public | sbtest9  | table | sbtest | 21 MB |
(24 rows)

Los datos de prueba ya están cargados.

Descargue el documento técnico hoy Administración y automatización de PostgreSQL con ClusterControlObtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar PostgreSQLDescargar el documento técnico

Generar cargas de prueba

Hay diferentes tipos de carga de trabajo de base de datos que puede realizar con sysbench, como se muestra en las siguientes secciones.

Carga de lectura/escritura

El comando es similar a la versión de MySQL de sysbench. Se pueden usar parámetros similares excepto los relacionados con PostgreSQL:

$ sysbench \
--db-driver=pgsql \
--report-interval=2 \
--oltp-table-size=100000 \
--oltp-tables-count=24 \
--threads=64 \
--time=60 \
--pgsql-host=192.168.55.61 \
--pgsql-port=5432 \
--pgsql-user=sbtest \
--pgsql-password=password \
--pgsql-db=sbtest \
/usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \
run

El comando anterior generará la carga de trabajo de OLTP desde el script LUA llamado /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua, contra 100 000 filas de 24 tablas con 64 subprocesos de trabajo durante 60 segundos en el host 192.168.55.61 (master ). Cada 2 segundos, sysbench informará las estadísticas intermedias (--report-interval=2 ).

Una vez ejecutado, obtendrías algo como lo siguiente:

sysbench 1.0.15 (using bundled LuaJIT 2.1.0-beta2)

Running the test with following options:
Number of threads: 16
Report intermediate results every 2 second(s)
Initializing random number generator from current time

Initializing worker threads...

Threads started!

[ 2s ] thds: 64 tps: 0.00 qps: 466.69 (r/w/o: 406.55/28.33/31.81) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00
[ 4s ] thds: 64 tps: 30.55 qps: 525.38 (r/w/o: 335.56/128.72/61.10) lat (ms,95%): 3639.94 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 64 tps: 39.55 qps: 718.41 (r/w/o: 496.13/142.68/79.60) lat (ms,95%): 4128.91 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 64 tps: 35.98 qps: 840.95 (r/w/o: 604.11/163.89/72.95) lat (ms,95%): 2198.52 err/s: 0.50 reconn/s: 0.00
[ 10s ] thds: 64 tps: 65.57 qps: 1314.94 (r/w/o: 912.00/271.80/131.14) lat (ms,95%): 3040.14 err/s: 0.00 reconn/s: 0.00
...

Cuando la prueba estaba en curso, podemos monitorear la actividad de PostgreSQL usando pg_activity o pg_top , para confirmar la estadística intermedia informada por sysbench. En otra terminal, haz:

$ su - postgres
$ pg_activity
 PostgreSQL 9.6.9 - postgres1.local - [email protected]:5432/postgres - Ref.: 2s
  Size:  654.62M -     7.67K/s        | TPS:          74
  Mem.:   39.10% -   382.72M/979.68M  | IO Max:     3395/s
  Swap:    0.20% -     3.57M/2.00G    | Read :      8.36M/s -   2141/s
  Load:    20.20 6.02 2.44            | Write:      2.54M/s -    650/s
                                                                   RUNNING QUERIES
PID    DATABASE              USER           CLIENT   CPU% MEM%   READ/s  WRITE/s     TIME+  W  IOW              state   Query
5130   sbtest              sbtest    192.168.55.61    1.0  2.8  791.57K    3.84K  0.788732  N    N             active   SELECT c FROM sbtest7 WHERE id BETWEEN 33195
 AND 33294
...

Así como el flujo de replicación mirando el pg_stat_replication tabla en el servidor maestro:

$ su - postgres
$ watch -n1 'psql -xc "select * from pg_stat_replication"'
Every 1.0s: psql -xc "select * from pg_stat_replication"      Tue Jul 31 13:12:08 2018
-[ RECORD 1 ]----+------------------------------
pid              | 3792
usesysid         | 16448
usename          | slave
application_name | walreceiver
client_addr      | 192.168.55.62
client_hostname  |
client_port      | 44654
backend_start    | 2018-07-30 13:41:41.707514+08
backend_xmin     |
state            | streaming
sent_location    | 0/60933D78
write_location   | 0/60933D78
flush_location   | 0/60933D78
replay_location  | 0/60933D78
sync_priority    | 0
sync_state       | async

El comando "watch" anterior ejecuta el comando psql cada 1 segundo. Debería ver que las columnas "*_ubicación" se actualizan en consecuencia cuando ocurre la replicación.

Al final de la prueba, debería ver el resumen:

SQL statistics:
    queries performed:
        read:                            67704
        write:                           19322
        other:                           9682
        total:                           96708
    transactions:                        4830   (79.34 per sec.)
    queries:                             96708  (1588.53 per sec.)
    ignored errors:                      6      (0.10 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          60.8723s
    total number of events:              4830

Latency (ms):
         min:                                    4.52
         avg:                                  799.70
         max:                                 8082.70
         95th percentile:                     2279.14
         sum:                              3862532.62

Threads fairness:
    events (avg/stddev):           75.4688/7.39
    execution time (avg/stddev):   60.3521/0.20

El resumen anterior nos dice que nuestro servidor de base de datos PostgreSQL puede manejar en promedio alrededor de 80 transacciones por segundo y alrededor de 1588 consultas por segundo en 64 subprocesos de trabajo.

Carga de solo lectura

Para la prueba de solo lectura, puede usar el mismo comando, pero cambie el script LUA a select.lua , seleccionar_puntos_aleatorios.lua , select_random_ranges.lua o oltp_simple.lua :

$ sysbench \
--db-driver=pgsql \
--report-interval=2 \
--oltp-table-size=100000 \
--oltp-tables-count=24 \
--threads=64 \
--time=60 \
--pgsql-host=192.168.55.62 \
--pgsql-port=5432 \
--pgsql-user=sbtest \
--pgsql-password=password \
--pgsql-db=sbtest \
/usr/share/sysbench/tests/include/oltp_legacy/select.lua \
run

El comando anterior ejecuta una carga de trabajo de solo lectura llamada select.lua contra un servidor esclavo de PostgreSQL (replicación de transmisión), 192.168.55.62 con 64 subprocesos de trabajo.

Otras Cargas

Hay muchas otras cargas de trabajo OLTP que puede generar con sysbench, como se enumeran en este directorio, /usr/share/sysbench/tests/include/oltp_legacy :

$ ls -1 /usr/share/sysbench/tests/include/oltp_legacy/
bulk_insert.lua
common.lua
delete.lua
insert.lua
oltp.lua
oltp_simple.lua
parallel_prepare.lua
select.lua
select_random_points.lua
select_random_ranges.lua
update_index.lua
update_non_index.lua

Puede usar un comando similar y cambiar la ruta al script LUA para cargarlo.

Reflexiones finales

Usando sysbench, podemos generar cargas de prueba para nuestro servidor PostgreSQL (así como para MySQL). Tenga en cuenta que el mejor punto de referencia sería con sus datos y aplicaciones reales, pero eso no siempre es posible. También podría ser una nueva aplicación que evolucionará rápidamente. A pesar de que la carga generada por sysbench puede no representar su carga de trabajo OLTP del mundo real, podría ser lo suficientemente buena.