PostgreSQL - POSTGRES deja de estar activo

Buenas noches,
Tengo un aplicativo que utiliza bd postgres, estuvo funcionando bien y de un momento a otro sale el siguiente error:

PHP Warning; pg_connect(): Unable to connect to PostgreSQL server: ERROR: pgbouncer cannot connect to server in /var/www/html/gpnextnew/model/gpn_devices_m/gpn_devices_m.php pn line 92

Esta linea es justo donde tiene la conexion a la base de datos.

Agradeceria si me pueden decir como identificar que proceso es el que hace que el servicio se detenga.

Gracias

Esta el servicio corriendo? o reiniciaron y el servicio no levanto correctamente? el servicio esta seteado para que inicie cuando inicie el OS? cierran la conexion despues hacer lo que tengan que hacer en el php? tal vez alcanzo el maximo de conexiones ya que quedan activas conexiones y se acumulan.

Sobre que OS esta instalado en postgresql?

Gracias por la pronta respuesta, contesto sus preguntas:
- Si el servicio corre correctamente y de un momento a otro no hay una hora fija sale el error que menciono y para que se restaure la unica forma es reiniciando el servidor.
- Si el servidor esta seteado para que inicie cuando inicie el OS
- Si hasta el 17 de junio corria sin ningun problema, por eso pienso que hay algun proceso (query) que esta haciendo esto, pero no se como identificar que proceso es.
- Como se que si alcanzo el maximo de conexiones o si pasa lo que me esta indicando, digame que debo de hacer para saberlo.
- El sistema operativo es Linux CentOS 5

Fijate en /var/lib/pgsql/data/pg_log y tambien puede ser algún problema de red, tendrias que ver la latencia o si hay cortes, más si me decis que el corte es aleatorio.

Muchas gracias estoy revisando el pg_log de ayer creo que ahi podre ver quien consume mas tiempo.
Por otro lado el tema del internet uso un enlace 1:1 solo para esos servidores que tiene 4Mb
Los servicios los veo a traves del Webmin y el de pgbounce cuando esta con el problema pasa de Si a Unkown

Tambien fijate el status del servicio cuando esto sucede con systemctl status postgresql.service o service postgresql status, no recuerdo que herramientas usa centos que siempre va por detras de fedora y demas

Estuve revisando el pg_log del miercoles y encontre que unas tablas que son las que tienen el historico de mi aplicacion demoran mucho o pienso que demoran mucho (8.274ms) cuando hacen el insert, este insert lo hacen desde otro servidor en la misma red en donde esta la base de datos y que como te dije es dedicada, esta hecho en visual basic, podrias decirme como mejorar esta velocidad, porque por ahi puede estar el problema pues hace como 3 meses que aumentaron las ocurrencias de insert yo diria que en un 20 por ciento.

EL insert tarda 8 segundos? y lo inserta otro servidor? otro postgresql?los insert tiene que tardar tanto, o son selects a los historicos?

Si se inserta desde otro servidor que es windows xp y que esta en la misma red que el servidor Linux.
Es un insert en una tabla historica que tiene varios registros que aproximadamente pesan en algunos casos 600Mb
Hace un momento se cayo, los archivos que estan en el directorio pg_log son bastante grandes que me aconseja para encontrar la caida?, estoy viendolos con more.

Gracias nuevamente por su apoyo

desde la consola lo mas básico seria un

grep -i "ERROR" /path/../pg_log > /home/tu_usuario/mi_log_filtrado_errores.txt

fijate el formato de la fecha en el log para filtrar justo cuando cae el servicio.

que te dice el status del servicio?

suerte

El servicio cuando sucede esto se coloca como Unkown.
Hice lo del grep y estoy analizando los mensajes de ERROR, lo mantendre en cuanto termine, le aviso.

Saludos,

Disculpa la molestia, pero conoces a alguien que pueda revisar mi plataforma en php y html y con base de datos postgres para que vea porque de un tiempo a esta parte se cuelga o anda lenta?.

mm no, que te dice el log? o postea la salida del grep

Sabes encontramos a que se debia este error, te lo explico por si en algun momento se presenta algo similar, resulta que esta base de datos tiene un schema que se llama history, este a su vez tiene particiones por los id de los usuarios que ingresan, aqui va guardando toda la informacion segun el id, pero resulta que este tabla tiene algo mas de 04 años y era enorme, entonces vimos que no hay procedimientos de borrado de esta data porque no ha sido particionada por fecha, se comenzo a borrar id por id y hemos notado que el problema ya no sucede, lo que nos da una idea que es porque la tabla principal era muy grande y hay querys que apuntan a ella y no a las particiones.