Hola!
Tenemos una instalacion de Omnileads recientemente actualizada a 1.10.4, instalado en un CentOS 7.
La arquitectura que se tiene es la siguiente: 1 servidor DESTINADO para la base de datos Postgres y el resto de componentes en otro servidor.
El dia de ayer los usuarios dejaron de poder accesar al sistema, en sus navegadores recibian las siguientes pantallas:
Se intento reactivar el sistema ejecutando el comando:
systemctl restart omnileads
Pero no se normalizaba el servicio.
Finalmente se tuvo que reiniciar el servidor de Applicacion de Omnileads para que el servicio se restablezca.
Despues de tener nuevamente funcionando el sistema, se procedio a realizar la busqueda de la causa raiz. No se encontraron mensajes determinantes ni en /var/log/messages, ni en /var/log/rtpengine/rtpengine.log ni en /opt/omnileads/asterisk/var/log/asterisk/full.
Pero en archivo /opt/omnileads/log/django.log se encontraron VARIAS lineas de logs a la hora que se reporto la falla. Esas lineas fueron:
psycopg2.OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections
django.db.utils.OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections
[ ERROR] reportes_app.management.commands.actualizar_reportes_llamadas_entrantes - Fallo del comando: FATAL: remaining connection slots are reserved for non-replication superuser connections
[ ERROR] ominicontacto_app.management.commands.actualizar_campanas_preview - Fallo del comando: FATAL: remaining connection slots are reserved for non-replication superuser connections
[ ERROR] root - Fallo del comando: FATAL: remaining connection slots are reserved for non-replication superuser connections
De acuerdo con la documentacion de framework Django, esos logs corresponde a que al parecer la aplicacion se quedo SIN conexiones disponibles hacia la base de datos Postgres.
Segun los foros, se podria solucionar de 2 maneras:
1) Aumentando el limite de conexiones concurrentes del lado de Postgres, aunque podria volver a darse el problema si Django no cierra de manera oportuna las conexiones ociosas.
He revisado que, del lado de Postgresql el limite de conexiones por defecto es solo 100. Lo cual me parece muy poco para un sistema que tiene un alto volumen de llamadas y agentes.
2) Disminuyendo el tiempo de las conexioneshechas por Django hacia la base de datos, modificando el parametro "CONN_MAX_AGE" en el Django.
He procedido a aumentar el limite de conexiones en la configuracion de Postgresql, pero no se en donde se puede configurar el parametro "CONN_MAX_AGE" del framework que maneja a Omnileads. En el portal de administracion de Django que viene en Omnileads (https://IP_OMNILEADS/admin) no existe ese acceso.
Me podrian ayudar a decir, en que archivo se podria hacer un tunning de ese parametro, cual es el valor por defecto y cual podria ser un valor recomendado para un sistema de alto volumen de llamadas con aproximadamente 150 agentes concurrentes?
Gracias!
