Parece que tiene una fuga de conexión en su aplicación porque no cierra las conexiones agrupadas . No tiene problemas solo con las <idle> in transaction
sesiones, sino con demasiadas conexiones en general.
Matar conexiones no es la respuesta correcta para eso, pero es una solución temporal aceptable.
En lugar de reiniciar PostgreSQL para arrancar todas las demás conexiones desde una base de datos PostgreSQL, consulte: ¿Cómo desconecto a todos los demás usuarios de una base de datos de Postgres? y ¿Cómo eliminar una base de datos PostgreSQL si hay conexiones activas a ella? . Este último muestra una mejor consulta.
Para configurar tiempos de espera, como sugirió @Doon, consulte ¿Cómo cerrar conexiones inactivas en PostgreSQL automáticamente? , que le aconseja utilizar PgBouncer como proxy para PostgreSQL y administrar las conexiones inactivas. Esta es una muy buena idea si tiene una aplicación con errores que de todos modos pierde conexiones; Recomiendo encarecidamente configurar PgBouncer.
Un keepalive de TCP no hará el trabajo aquí, porque la aplicación todavía está conectada y viva, simplemente no debería estarlo.
En PostgreSQL 9.2 y superior, puede usar la nueva state_change
columna de marca de tiempo y el state
campo de pg_stat_activity
para implementar un reaper de conexión inactiva. Haga que un trabajo cron ejecute algo como esto:
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'regress'
AND pid <> pg_backend_pid()
AND state = 'idle'
AND state_change < current_timestamp - INTERVAL '5' MINUTE;
En versiones anteriores, debe implementar esquemas complicados que realicen un seguimiento de cuándo la conexión quedó inactiva. No molestar; solo usa pgbouncer.