Es hört sich so an, als hätten Sie ein Verbindungsleck in Ihrer Anwendung, weil es gepoolte Verbindungen nicht schließen kann . Sie haben keine Probleme nur mit <idle> in transaction Sitzungen, aber insgesamt mit zu vielen Verbindungen.
Das Beenden von Verbindungen ist dafür nicht die richtige Antwort, aber es ist eine vorübergehende Problemumgehung.
Anstatt PostgreSQL neu zu starten, um alle anderen Verbindungen von einer PostgreSQL-Datenbank zu booten, siehe:Wie trenne ich alle anderen Benutzer von einer Postgres-Datenbank? und Wie lösche ich eine PostgreSQL-Datenbank, wenn aktive Verbindungen zu ihr bestehen? . Letzteres zeigt eine bessere Abfrage.
Informationen zum Festlegen von Zeitüberschreitungen, wie von @Doon vorgeschlagen, finden Sie unter So schließen Sie Leerlaufverbindungen in PostgreSQL automatisch?, in dem Sie aufgefordert werden, PgBouncer als Proxy für PostgreSQL zu verwenden und Leerlaufverbindungen zu verwalten. Dies ist eine sehr gute Idee, wenn Sie eine fehlerhafte Anwendung haben, die sowieso Verbindungen verliert; Ich sehr stark empfehlen die Konfiguration von PgBouncer.
Ein TCP-Keepalive wird hier nicht ausreichen, da die App immer noch verbunden und am Leben ist, das sollte es einfach nicht sein.
In PostgreSQL 9.2 und höher können Sie den neuen state_change verwenden timestamp-Spalte und den state Feld von pg_stat_activity um einen Idle-Connection-Reaper zu implementieren. Lassen Sie einen Cron-Job etwa so laufen:
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;
In älteren Versionen müssen Sie komplizierte Schemata implementieren, die nachverfolgen, wann die Verbindung in den Leerlauf gegangen ist. Nicht stören; Verwenden Sie einfach pgbouncer.
