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:alvhe...@2ndquadrant.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@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
