Inicie sesión para poder revisar sus tickets
TICK-003202 - Sobrecarga de bbdd de reggio.cl
Ticket Resuelto
Cliente:
Fernando Ríos (OrionERP)
Equipo:
Nivel 1
Ejecutiv@:
Liset Gilewski (OrionERP)
Fecha de creación:
Email:
Teléfono:
Fecha de cierre:
23/08/2022 12:51:16
Categoría:
Reportar un error
Descripción:
Problemática:
1. Cliente no puede acceder rápidamente a su bbdd
1.1 Sitio web home y sitio web de inicio de sesión de sesión demoran hasta 10 minutos en cargar
1.2 Una vez que ingresa, puede navegar con mayor rapidez
2. Cliente no puede imprimir reportes de facturas
2.1 Sistema demora indefinidamente al realizarle dicha peticion
Diagnóstico:
1. BBDD del cliente pesa 90 GB (normalmente a lo sumo pesan 2GB luego de un año de contrato)
2. Tablas mail.message, mail.message.dte e ir.attachment presentan aproximadamente 9.000.000 de registros
2.1 Tablas generan aproximadamente 10 registros por segundo
3. 250 correos aproximadamente en dte@transformadoresreggio.orionerp.cl que aparecen como no leídos
4. Servidor de correo entrante de reggio.cl está configurado como POP (no como IMAP en los demás clientes)
Análisis:
1. Debido al volúmen de registros en la tabla, se postula que un bucle de ejecución esté creando sistemáticamente estos registros
2. La tabla mail.message.dte es aquella que está asociada a los registros generados derivados de la recepción de correos en la casilla dte@cliente.orionerp.cl
3. El sistema consulta periodicamente la casilla dte@cliente.orionerp.cl para detectar si hay correos no leídos, para luego descargarlos al sistema y generar un registro en la tabla mail.message.dte
3.1 Debido a que, o bien los correos no se eliminaban en este proceso, o no se marcaban como leídos, pudiendo estas condiciones ser provocadas por el protocolo POP, o bien debido a algun correo malicioso entrante, es que el sistema intenta crear registros en mail.message.dte constantemente, sin un criterio para dejar de hacerlo. Se postuló en un comienzo que era spam de terceros, pero se descartó esta posibilidad.
Testeos:
1. Se generó un entorno de prueba de reggio.cl
2. Se marcaron como leídos los correos de dte@transformadoresreggio.orionerp.cl
2.1 El sistema dejó de crear registros en tabla mail.message.dte
3. Se deshabilita temporalmente servidor de correos entrantes dte@transformadoresreggio.orionerp.cl y catchall@transformadoresreggio.orionerp.cl
4. Se procede a hacer queries para desduplicar los records afectados eliminando los records duplicados en la tabla mail.message.dte
4.1 Usando queries compuestas con SELECT y DELETE, no se consiguió un rendimiento óptimo de desduplicación, demorandose cada record más de 1 segundo en ser procesado debido al gran volúmen de datos y relaciones de la tabla mail.message.dte con la tabla mail.message, y mail.message con ir.attachment, ambas via llave foránea. Lo anterior implica un intento por realizar un borrado de cascada de las tres tablas, resultando en un tiempo de ejecución indefinido. Por su parte, en la tabla ir.attachment existe un campo que indexa el contenido del adjunto, y siendo el contenido del XML extenso para un campo tipo char (5000 caracteres) y el único hábil para distinguir un record de otro para estos fines, el almacenamiento de esta data para su análisis ralentiza aún más la consulta.
5. Se evalúa impacto de borrar por completo los registros de mail.message.dte sin distinguir duplicados
5.1 Borrado de mail.message.dte eliminaría los XML recibidos históricamente, pero no afectaría a otros modelos como mail.message.dte.document o account.invoice
5.2 En caso de que cliente desee generar las facturas de proveedor faltantes, se deberá recurrir a métodos alternativos para generar dichas facturas
5.3 En caso de que cliente solicite un respaldo de dichos XML, no existirá dicho respaldo en su bbdd
5.3.1 Se contará de todos modos con un respaldo de dichos XML gracias a un backup del servidor donde se aloja reggio.cl
5.3.2 Procesar dicho backup para desduplicar los XML y descargarlos requerirá técnicas de Big Data
5.4 La evaluación sugiere que debido a la necesidad primordial de dar continuidad al servicio, se borre por completo los registros de mail.message.dte y en el caso de borde de que
el cliente solicite un backup de sus XML de proveedor, se recurra al método de desduplicación de tres tablas de 9.000.000 de records
6. Se procede a hacer una query de tipo TRUNCATE en mail.message.dte para borrar todos los registros en dicha tabla
6.1 9.000.000 de records en mail.message.dte se eliminan en un solo segundo
7. Se procede a hacer una query de tipo DELETE en la tabla mail.message aplicándose un filtro en el campo res_model con valor 'mail.message.dte'
7.1 Se eliminan todos los records de dicha tabla que cumplan con esa condición
8. Se procede a hacer una query de tipo DELETE en la tabla ir.attachment aplicándose un filtro en el campo model con valor 'mail.message.dte'
8.1 Se eliminan todos los records de dicha tabla que cumplan con esa condición
9. BBDD reduce drásticamente su volúmen y tiempos de ejecución mejoran notoriamente
10. Se rehabilita servidor de correos entrantes dte@transformadoresreggio.orionerp.cl y catchall@transformadoresreggio.orionerp.cl con configuración IMAP
Solución en producción:
1. Se deshabilita temporalmente servidor de correos entrantes dte@transformadoresreggio.orionerp.cl y catchall@transformadoresreggio.orionerp.cl
2. Se efectúa una query de tipo TRUNCATE en mail.message.dte mediante el comando cr de env
3. Se crean dos crons para realizar los pasos 7 y 8 respectivamente de los tests, seteados a ejecutarse con un límite de records de 1.000.000 en cada caso, con un máximo de 10 ejecuciones cada uno
4. Se rehabilita servidor de correos entrantes dte@transformadoresreggio.orionerp.cl y catchall@transformadoresreggio.orionerp.cl con configuración IMAP
Conclusión:
1. Crons podrían demorar en eliminar todos los registros afectados entre 2 a 3 horas en bbdd de produccion
2. Protocolo de servidor de correos entrantes en bbdd de clientes debe ser siempre IMAP