Lentitud en consulta a la base con la nueva versión

Buenas tardes,

Desde que pasamos de la 3.16.2 a la 3.20.1, estamos teniendo lentitud al hacer consultas a la base de datos. Esto lo detectamos en una operación nuestra que ejecuta una query de consulta con varios joins. Antes tardaba 2s y ahora 2min 50s. Como principal usa la vista vw_regularidades_basica que hago un “select * from vw_regularidades_basica” tarda 36s. La tabla tiene unos 923mil registros que es aprox lo que teniamos antes en la 3.16. Lo que me resulta raro es que si ahora ejecuto la consulta con un backup de la 3.16 me tarda 36s, lo msimo que ahora con la base migrada a la 3.20; con esto supongo que el problema no está en la query ni en los datos. Nos estará faltando algo a la en la configuración de postgres? Ya que al cambiar de versión de Guarani tuvimos que actualizar postgres a la versión 11. Muchas gracias.

Agustín

Buenas tardes. Saben si ya había pasado algo por el estilo? Gracias.

Hola Agustin

Seria posible que adjuntaras el archivo de configuracion postgresql.conf que usaban en la version anterior de postgres y el actual ? los comparamos y nos sacamos la duda. Si no tenes el anterior, pasanos solo el actual

saludos
Ignacio

Buenas tardes. Gracias por responder. Les adjunto los archivos. Las diferencias que encontré fueron:

-Postgres 9:
#max_wal_size = 1GB
#min_wal_size = 80MB

-Postgres 11:
max_wal_size = 1GB
min_wal_size = 80MB


-Postgres 9:
max_locks_per_transaction = 2048

-Postgres 11:
#max_locks_per_transaction = 64

Gracias


postgres_conf.zip (14.9 KB)

Hola Agustin

Las diferencias entre ambas configuraciones no son significativas. (solo hay un parámetro que cambia, y es relacionado a los locks)

Lo que queda es tratar de identificar los queries que son lentos ahora. Seria posible ?

Se me ocurre, que podriamos activar los logs de postgres y durante la operación lenta, mirar el log a ver que queries se ejecutan y cuanto demoran

para activar los logs de postgres, hay que modificar los parámetros

log_min_duration_statement = 0
y
log destination si corresponde, porque quizás ya esta apuntando al log

saludos
Ignacio

Hola Agustin, corrieron el VACUUM ANALYZE ?

Buenas tardes,

Perdòn que contesto ahora, es que dejamos de lado este tema porque teniamos otras cosas más urgentes. Si, acabo de correrlo asì:

VACUUM FULL;
REINDEX DATABASE GUARANI3;

Pero sigue tardando. Alguna otra cosa que pueda ser?
Les paso la query que estoy probando y tarda 17seg, cuando antes tardaba 2seg:


SELECT
                        *
                FROM
                        --vw_regularidades
                        vw_regularidades_basica as vw_regularidades--
                        LEFT JOIN sga_alumnos ON sga_alumnos.alumno = vw_regularidades.alumno--
                        LEFT JOIN sga_propuestas ON sga_propuestas.propuesta = sga_alumnos.propuesta--
                        LEFT JOIN sga_planes_versiones ON sga_planes_versiones.plan_version = vw_regularidades.plan_version --
                        LEFT JOIN sga_planes ON sga_planes.plan = sga_planes_versiones.plan --
                        LEFT JOIN sga_instancias_resultado ON (sga_instancias_resultado.instancia = vw_regularidades.instancia AND--
                                                               sga_instancias_resultado.resultado = vw_regularidades.resultado)   --
                        LEFT JOIN vw_comisiones ON vw_comisiones.comision = vw_regularidades.comision --
                WHERE true
                 AND sga_alumnos.legajo = '1509536' and sga_planes.codigo = 'K08'


Gracias

Saludos

Hola,

Si tuvieramos los 2 explains, uno de cuando la consulta tardaba 2 segundos y otro de ahora seria muy bueno para entender que pasa

se puede conseguir el explain de cuando tardaba 2 segundos ? De ser posible conseguirlo, haria tambien un exlpain analyze

saludos
Ignacio

Hola Agustin, como va. Vamos a analizar un poco la consulta.

  1. Los siguiente LEFT JOIN no tienen razon de ser que sea LEFT JOIN porque en la vista vw_regularidades_basica el dato “alumno” existe siempre.

LEFT JOIN sga_alumnos ON sga_alumnos.alumno = vw_regularidades.alumno--
LEFT JOIN sga_propuestas ON sga_propuestas.propuesta = sga_alumnos.propuesta--
LEFT JOIN sga_planes_versiones ON sga_planes_versiones.plan_version = vw_regularidades.plan_version --
LEFT JOIN sga_planes ON sga_planes.plan = sga_planes_versiones.plan

Deberia ser:

JOIN sga_alumnos ON sga_alumnos.alumno = vw_regularidades.alumno
JOIN sga_propuestas ON sga_propuestas.propuesta = sga_alumnos.propuesta
JOIN sga_planes_versiones ON sga_planes_versiones.plan_version = vw_regularidades.plan_version 
JOIN sga_planes ON sga_planes.plan = sga_planes_versiones.plan 

Es mas, si el filtro lo hacen buscando siempre por un alumno (en este caso por el dato legajo), cambiaría el orden de las tablas
FROM sga_alumnos
JOIN vw_regularidades_basica as vw_regularidades ON vw_regularidades.alumno = sga_alumnos.alumno

WHERE true
AND sga_alumnos.legajo = ‘xxxxxxxx’

  1. Respecto del LEFT JOIN con la vista de comisiones estaría bien si es que podrian recuperarse equivalencias de regularidad.

El problema se da cuando se accede a la vista vw_regularidades_basica con mas de un alumno.
Si probas el filtro:

WHERE sga_alumnos.alumno = <ALUMNO>

Veras que el tiempo de respuesta es aceptable

  1. En la operacion Reporte de Vencimiento de Regularidad, hubo un cambio en la version 3.20.1 (Ticket #42105), por este problema de que la query tardaba mucho tiempo en devolver los datos. Por lo que veo estan en esta operación. Pueden verificar si tienen problemas en este reporte?

Buenas noches!. Eran las querys que estaban mal, las estaba haciendo por legajo y no por alumno como me comentaste. No entiendo como antes no habìa lentitud si no se habìan modificado. Puede ser que en algo me haya confundido. Asi que ya quedó solucionado. Muchas gracias!

Agustín

Buenisimo Agustin, gracias por avisar.

saludos
Ignacio