RE: Ayuda - Rendimiento muy malo con Synchronous Commit

Alvaro muchas gracias por la pronta respuesta, sobre los discos tengo que
investigar más porque el server es un VPS contratado que tiene dos discos
SSD.

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? He ejecuta el test con el mismo scale factor por
defecto y con un solo usuario conectado y los resultados siguen siendo los
mismos.

Porque me comentas que la idea es que el scale debería ser al menos tan
grande como el núm de clientes? Por número de clientes te refieres a
usuarios concurrentes ejecutando el test?

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
number of threads: 12
duration: 60 s
number of transactions actually processed: 88778
latency average = 54.094 ms
latency stddev = 58.416 ms
tps = 1475.415857 (including connections establishing)
tps = 1475.526722 (excluding connections establishing)

Tengo la impresión de que estos resultados podrían ser mucho mejores, que
crees??

Como podría hacer un test del fsync??

Saludos.

-----Mensaje original-----
De: Alvaro Herrera [mailto:alvherre(at)2ndquadrant(dot)com]
Enviado el: viernes, 31 de marzo de 2017 10:29 a. m.
Para: Lazaro Garcia
CC: 'Ayuda'
Asunto: Re: [pgsql-es-ayuda] Ayuda - Rendimiento muy malo con Synchronous
Commit

Lazaro Garcia escribió:

> scaling factor: 1

> number of clients: 50

> Analizando el log de postgres con pgbadger pude ver que los updates
> demoran enormemente para una tabla con 10 tuplas solamente. Luego
> ejecuté un explain analyze y los resultados del explain se contradicen a
lo que arroja el test:
>
>
>
> Update on pgbench_tellers (cost=4.14..8.16 rows=1 width=358) (actual
> time=0.021..0.021 rows=0 loops=1)

Este test no tiene sentido. Si la tabla es muy pequeña, los update van a
estar en conflicto permanente unos con otros, y por supuesto eso demorará.
Repite el test con un "scale" mayor (entiendo que la idea es que el scale
debería ser al menos tan grande como el núm de clientes)

Dicho eso, ni siquiera mencionaste la configuración de discos (así que
seguramente son lentos), y el sinc commit es sobre todo un test a qué tan
rápido puedes hacer flush a disco.

--
Á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(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda