Buenos días a todos, en esta ocasión les escribo para compartir con ustedes
los resultados finales y algunos errores que estuve cometiendo durante el
test. De igual forma cualquier contribución es apreciada.
Primeramente el intervalo en que un checkpoint se estaba ejecutando era de 5
min y esto ocasionaba muchos checkpoints.
Tambien max_wal_size estaba a 1 GB demasiado corto incluso para este tiempo
pues el test durante 5 minutos estaba generando aproximadamente 2 GB de
ficheros WAL, al alcanzar 1 GB se lanzaba otro checkpoint y
checkpoint_completion_target estaba a 0.5 o sea que en los primeros 2.5
minutos el checkpoint debía terminar.
La solución fue incrementar checkpoint_timeout a 30 min,
checkpoint_completion_target = 0.9 y max_wal_size al triple del tamaño de
wals que se deben generar en 30 minutos.
Para que el test tuviera efecto se ejecutó con un scale de 200 y 40 usuarios
concurrentes, un número elevado de usuarios generaba contención en la base
de datos. La ejecución del test tras estas configuraciones fue de 1 hora
para ver que sucedía durante la ejecución de algún checkpoint, el IO de
server después de 30 minutos comenzó a subir y el número de transacciones
comenzó a disminuir pero se mantuvo más estable obteniendo como promedio 950
TPS (test completo ejecutando inserciones y actualizaciones).
Ejecutar test con tiempos cortos daba resultados muy diferentes pues
mientras no se ejecutaban checkpoints todo parecía estar bien, tras el
checkpoint el rendimiento decaía y un tiempo de 60 minutos era muy corto
para sacar un resultado fiable. Además mientras más veces se ejecutaba el
test, mas tuplas muertas había en la base de datos y tras ejecutar un vacuum
muchas páginas se limpiaban.
En modo solo lectura ( pgbench -S) está entre 70 mil y 80 mil TPS.
El disco duro es un disco SATA de 7200 RPM:
ATA device, with non-removable media
Model Number: TOSHIBA DT01ACA200
Serial Number: Z4NMKKGAS
Firmware Revision: MX4OABB0
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions,
SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0;
Saludos a todos.
-----Mensaje original-----
De: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
Enviado el: viernes, 31 de marzo de 2017 12:02 p. m.
Para: Lazaro Garcia
CC: 'Ayuda'
Asunto: Re: [pgsql-es-ayuda] Ayuda - Rendimiento muy malo con Synchronous
Commit
Lazaro Garcia escribió:
> Nuevamente realicé el test con un scale de 100 y 80 usuarios
> concurrentes durante 60 segundos como me sujeriste, el resultado fue el
siguiente:
> scaling factor: 100
> query mode: simple
> number of clients: 80
> tps = 1475.415857 (including connections establishing) tps =
> 1475.526722 (excluding connections establishing)
Es decir de 91 tps iniciales subiste a 1475 tps. Suena bastante mejor, ¿no
te parece?
(60s es un tiempo bastante corto. Deberías probar al menos el tiempo
suficiente para que ocurra unos pocos checkpoints, para asegurarte que tus
resultados son sostenibles)
> Como podría hacer un test del fsync??
Existe pg_test_fsync.
> Sobre tu primera respuesta me podrías explicar porque mientras más
> chica la tabla y mayor el número de clientes (usuarios conectados a la
> base) el update demoraría más?
Porque cada uno tiene que esperar a que otro que esté modificando la misma
tupla termine.
> He ejecuta el test con el mismo scale factor por defecto y con un solo
> usuario conectado y los resultados siguen siendo los mismos.
Bueno, con un solo usuario obviamente no hay ninguna concurrencia.
> Porque me comentas que la idea es que el scale debería ser al menos
> tan grande como el núm de clientes?
Para evitar contención.
> Por número de clientes te refieres a usuarios concurrentes ejecutando
> el test?
Me refiero al -c de pgbench.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
