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 estoy de acuerdo con usted, la
configuracion puede necesitar algunas puntualizaciones pero un cambio
en la arquitectura que mejore el consumo y gestion de las conexiones
seria de muchisima ayuda asi como una revision mas exaustiva en el uso
de los indices como dijo Alvaro al inicio de este chat.
Hay alguna manera de demostrar/monitoriar que postgres por el solo no
esta manejando de la mejor manera esta situacion y requiere la ayuda
de una herramienta externa como pgBoncer?
Tienes New Relic, usa New Relic para monitorear el postgres.
Por cierto, anteriormente me equivoque al comentar los recursos
fisicos de este servidor, aqui los rectificos:
Memory: 512 GB
Procesadores: 2 procesadores, 6 cores por procesador, lo que da 12 a
2.5GHz.
HD: son SAS, 15K RPM 6 Gb/s.
Saludos,
Carlos
On Sat, Jan 12, 2019 at 4:44 PM Eduardo Morras <emorr...@yahoo.es
<mailto:emorr...@yahoo.es>> wrote:
On Thu, 10 Jan 2019 22:08:59 -0600
"Carlos T. Groero Carmona" <cton...@gmail.com
<mailto:cton...@gmail.com>> 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%. Revisamos la tabla
> pg__stat_activity, existian ~ 375 procesos en espera de escribir en
> la tabla donde estaba el lock, encontramos el lock, lo eliminamos y
> el resto de los procesos desaparecieron.
>
> revisando los logs encontre:
> LOG: process 1234 still waiting for ShareLock on transaction
zzzzzzzz
> after 5000.237 ms
> 1234 ERROR: canceling statement due to lock timeout ...el
mismo PID
> nota: lock_timeout = 10s
>
> y por cada update que estaba esperando encontre un sharedlock,
pero no
> habia nada en los logs acerca de los insert que encontre en
> pg_stat_activity que ivan a ejecutarse en la misma tabla donde
> estaban los locks.
>
> Calcule el thresold de la tabla y es solo un 24%.
>
> Pos lo que les quiero preguntar:
> 1. hay alguna manera de prevenir que esto suceda?
> 2. Existe alguna herramienta para monitorear los locks de mi base de
> datos?
>
Nuevamente, la mejor medida que se puede tomar es disminuir el
número de conexiones. En el primer correo decías que tenías 600,
es una exageración, incluso para un servidor con 128 núcleos. En
este caso, al llegar a 377 transacciones el sistema quedo en
deadlock. Disminuye el número de conexiones a 32 o 40 y usa
pgbouncer por delante para soportar el volumen de conexiones. Te
aseguro que usarás casi todos los núcleos si usas PG10+.
Puede que tengas procesadores de sobra y memoria de sobra, pero el
sistema operativo también impone límites, así como los discos
duros y resto del hardware. Tantas transaciones se "pegan" por
adquirir acceso a los recursos más debiles, provocando que la
mayor parte del tiempo de proceso se pierda en gestionar los
accesos a dichos recursos, por ejemplo el tiempo de lectura y
escritura a los discos es finito o el número de descriptores de
archivo que permite el sistema ser bajo para tu configuración de
postgres.
El valor de work_mem que sugerí, era un aumento sobre el valor por
defecto de postgres para poder procesar transacciones más
complejas usando solo memoria, sin archivos temporales más lentos.
Si ya lo tenias en 128MB, no hace falta disminuirla. No obstante,
esos 128MB se multiplican por cada conexión abierta y dado que hay
600 son muchos recursos de memoria desperdiciados.
Insisto, la solución creo que va más por problema de arquitectura
que de configuración, usa pgbouncer, lo puedes instalar incluso en
el mismo servidor y disminuye el número de conexiones en postgres
a 20-40, pgbouncer se encargará de gestionar todas las conexiones,
300 o 600 o 1000, de manera transparente para Postgresql. Además
podrás aumentar también el work_mem todavía más
> En fin, cualquier ayuda o sugerencia sera apreciada.
>
> Saludos
Saludos
--- ---
Eduardo Morras <emorr...@yahoo.es <mailto:emorr...@yahoo.es>>
