Re: Dificil situacion con Lokcs...

On 15/01/2019 5:55 AM, Carlos T. Groero Carmona wrote: Eduardo gracias por su explicacion, voy a enfocar mis esfuerzos hacia ahi, creo que el uso de pgBouncer ayudara mucho, solo que debo demostrar que esto es necesario, estaba evitando proponer un cambio en la arquitectura por ahora, pero

Re: Dificil situacion con Lokcs...

On 11/01/2019 5:08 PM, Carlos T. Groero Carmona wrote: Hola amigos, Hola, puedes por favor revisar ese update ( es posible que lo compartas, con datos ofuscados sirve ), tengo la sospecha que estas haciendo un update con un datos sacado de un select y puede que estes haciendo un

Re: Dificil situacion con Lokcs...

On 6/01/2019 12:01 PM, Daymel Bonne wrote: Hola: El sáb., 5 de ene. de 2019 a la(s) 17:43, Carlos T. Groero Carmona (cton...@gmail.com ) escribió: Alvaro escribio: Como tienes lock_timeout, tu problema seguramente no fue de locks sino

Re: Dificil situacion con Lokcs...

On Wed, 16 Jan 2019 23:42:22 -0600 "Carlos T. Groero Carmona" wrote: > Gracias Jaime y Eduardo por sus comentarios y la documentacion > > Me encuentro trabajando en una propuesta para cambiar el # > max_connection e incluir pgBouncer en la arquitectura. > > Solo una pregunta, si existe una

Re: Dificil situacion con Lokcs...

Gracias Jaime y Eduardo por sus comentarios y la documentacion Me encuentro trabajando en una propuesta para cambiar el # max_connection e incluir pgBouncer en la arquitectura. Solo una pregunta, si existe una metrica para calcular el max_connection porque no se encuentra esta informacion en el

Re: Dificil situacion con Lokcs...

La asignación típica de max_connections suele estar en el orden de ((core_count * 2) + effective_spindle_count , que en tu caso oscilará entre 24 conexiones, como referencia tienes el artículo de la wiki: https://wiki.postgresql.org/wiki/Number_Of_Database_Connections Aunque hay múltiples libros

Re: Dificil situacion con Lokcs...

On Mon, 14 Jan 2019 10:55:56 -0600 "Carlos T. Groero Carmona" wrote: > Eduardo gracias por su explicacion, voy a enfocar mis esfuerzos hacia > ahi, creo que el uso de pgBouncer ayudara mucho, solo que debo > demostrar que esto es necesario, estaba evitando proponer un cambio > en la arquitectura

Re: Dificil situacion con Lokcs...

Eduardo gracias por su explicacion, voy a enfocar mis esfuerzos hacia ahi, creo que el uso de pgBouncer ayudara mucho, solo que debo demostrar que esto es necesario, estaba evitando proponer un cambio en la arquitectura por ahora, pero estoy de acuerdo con usted, la configuracion puede necesitar

Re: Dificil situacion con Lokcs...

On Thu, 10 Jan 2019 22:08:59 -0600 "Carlos T. Groero Carmona" wrote: > > > > Hola amigos, > >> > > > Hoy volvio a suceder la situacion con los locks, la situacion fue la > misma y en la misma tabla, la query es casi la misma, recivimos una > alerta de New Relic, el uso del CPU subio ~100%.

Re: Dificil situacion con Lokcs...

> > Hola amigos, >> > Hoy volvio a suceder la situacion con los locks, la situacion fue la misma y en la misma tabla, la query es casi la misma, recivimos una alerta de New Relic, el uso del CPU subio ~100%. Revisamos la tabla pg__stat_activity, existian ~ 375 procesos en espera de escribir en la

Re: Dificil situacion con Lokcs...

Eduardo gracias por su consejo, coincido con usted y es lo que he estado haciendo. Actualmente el work_mem es the 128 MB, yo estoy de acuerdo con usted que debe ser 32 MB, es el valor que habia puesto en mi propuesta de cambios, pero ahora solo quiero enfocarme en optimizar todo lo que se pueda

Re: Dificil situacion con Lokcs...

Carlos T. Groero Carmona escribió: > Daymel, gracias por su comentario. > > He estado manejando hipotesis donde el update se bloquea porque se queda > esperando una validacion (otro query o trigger), se demora mas de 5 > segundos, el lock_timeout le dice a postgres que elimine esa transaction, >

Re: Dificil situacion con Lokcs...

Daymel, gracias por su comentario. He estado manejando hipotesis donde el update se bloquea porque se queda esperando una validacion (otro query o trigger), se demora mas de 5 segundos, el lock_timeout le dice a postgres que elimine esa transaction, la transaction se queda abierta, el script

Re: Dificil situacion con Lokcs...

Hola: El sáb., 5 de ene. de 2019 a la(s) 17:43, Carlos T. Groero Carmona ( cton...@gmail.com) escribió: > Alvaro escribio: >> > > Como tienes lock_timeout, tu problema seguramente no fue de locks sino >> de lentitud. >> > > Por lo que me surge la duda, todo parece indicar que la transaction se >

Re: Dificil situacion con Lokcs...

> > Alvaro escribio: > Como tienes lock_timeout, tu problema seguramente no fue de locks sino > de lentitud. > Por lo que me surge la duda, todo parece indicar que la transaction se inicia con el update pero por algun problema de lentitud se queda esperando una respuesta, durante ese tiempo la

Re: Dificil situacion con Lokcs...

Carlos T. Groero Carmona escribió: > actualmente tengo una base de datos en postgres 9.3, hay un script que esta > tratando de actualizar una fila en una tabla, es un simple update, pero hoy > se trataron de ejecutar 388 procesos con el mismo querry (conte cuantos > procesos habian en

Dificil situacion con Lokcs...

Hola a todos, actualmente tengo una base de datos en postgres 9.3, hay un script que esta tratando de actualizar una fila en una tabla, es un simple update, pero hoy se trataron de ejecutar 388 procesos con el mismo querry (conte cuantos procesos habian en pg_activity con el mismo query) y se