compañeros
muchas gracias esta ultima prueba ya salio y funciono.
comento que uno de los factores que se checaron hasta hace un par de horas
fue un
query muy grande el cual se estaba tardando por falta de indices que no me
habia percatado,
hice pruebas de solo dejar el indice sin las actuales
hola lista!!
hoy estoy en pruebas y estoy por reprobarlas si el postgres no le doy mas
velocidad a las base de datos,
ya estan estresando el programa y el sistema y todo va bien solo k empiezan
a alentarse las consultas, tengo
a la bd principal aproximadamente 74 cnsutlas concurrentes (lo obtube
2010/7/9 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com:
adjunto mi conf de postgres
max_connections = 2000 (esto esta demasiado alto)
superuser_reserved_connections = 20 ()
work_mem = 64MB (con max_connections en 2000 este valor es muy alto;
si usaras un pool de conexiones y
Hola jaime
como puedo configurar esto, donde puedo ver cuales son las consultas de mas
de 3 segundos
y si hay que activar algo mas??
*#log_min_duration_statement = -1
activa esto y pon que te muestre las consultas que demoran mas de 3s y
asi para ir chequeando las consultas lentas y que porque
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Miguel Angel Hernandez Moreno wrote:
hola lista!!
hoy estoy en pruebas y estoy por reprobarlas si el postgres no le doy
mas velocidad a las base de datos,
ya estan estresando el programa y el sistema y todo va bien solo k
empiezan a alentarse
*Con los datos que das, poco te vamos a poder ayudar de manera concreta.
¿Que version de PostgreSQL utilizas?
¿Que tipo de uso se le da a la base de datos, escrituras vs. lecturas?
¿Cual es el uso de los recursos del sistema cuando las cosas empiezan a
funcionar mas lentas, cpu, memoria, IO?
envio el resultado de mi vaccum
INFO: vacuuming monterrey.boleturavl_2010_07_09INFO: scanned index
unicos2_boleturavl_2010_07_09 to remove 1102 row versions
DETAIL: CPU 0.16s/0.61u sec elapsed 5.22 sec.INFO: scanned index
idx_hreal_eco_bol2_boleturavl_2010_07_09 to remove 1102 row versions
2010/7/9 Miguel Angel Hernandez Moreno miguel.hdz@gmail.com:
Postgres 8.4.3
Pero el postgresql.conf que pasaste es de 8.3 yo por eso dije lo del
VACUUM VERBOSE, en el 8.4 no necesitas configurar max_fsm_*
definitivamente debes modificar los parametros
autovacuum_*_scale_factor, en 8.4 el
Hermano, necesitamos para ayudarte la configuracion que tienes en tu
postgresql.conf.
Saludos
El 9 de julio de 2010 14:16, Miguel Angel Hernandez Moreno
miguel.hdz@gmail.com escribió:
hola lista!!
hoy estoy en pruebas y estoy por reprobarlas si el postgres no le doy mas
velocidad a las
