Website ausgefallen: PostgreSQL lehnt neue Verbindungen ab

Kritische Situation: Die Anwendung meldet too many connections. Das Team erhöht die Workerzahl, während die Anwendung ständig neu versucht. Die Gegenmaßnahme kann die letzten verfügbaren Datenbankverbindungen verbrauchen.

Zuerst die Verbindungswelle begrenzen

Begrenzen Sie vorübergehend automatisches Workerwachstum und unnötige Aufträge. Hat eine neue Version Prozesszahlen oder Poolgrößen geändert, prüfen Sie genau diese Änderung. Eine Wartungsseite oder weniger Eingangslast im betroffenen Bereich kann Diagnosezeit schaffen. Ziel ist, die Druckerzeugung zu stoppen, nicht grundlos sämtliche Dienste abzuschalten.

Über eine Verwaltungsverbindung prüfen

Ist noch ein reservierter Platz vorhanden, kann eine entsprechend berechtigte Verwaltungsrolle möglicherweise verbinden. Eine lokale Verbindung umgeht das Verbindungslimit nicht automatisch. Führen Sie in der PostgreSQL-Verwaltungssitzung diese lesenden Abfragen aus:

SHOW max_connections;

SELECT application_name, usename, state, count(*) AS sessions
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY application_name, usename, state
ORDER BY sessions DESC;

Die Ausgabe hilft, Anwendungen oder Konten mit vielen Sitzungen zu finden. Details fremder Sitzungen erfordern passende Rechte. Viele idle-Verbindungen beweisen kein Leck; ein großer Pool kann sie erklären. idle in transaction unterscheidet sich von einer inaktiven Verbindung ohne offene Transaktion.

Die Maßnahme an die Ursache anpassen

Bringen Sie Poolobergrenzen und Prozesszahl der verbindungserzeugenden Anwendung wieder innerhalb des gemeinsamen Datenbankbudgets. Im hypothetischen Fall kann das Zurücknehmen der Workerkonfiguration sinnvoller sein als sofort mehr max_connections. Eine Erhöhung benötigt zusätzliche Ressourcen und einen Serverneustart; sie beseitigt weder Lecks noch Wiederholungsstürme automatisch.

Ist eine bekannte aktive Anfrage verantwortlich, erwägen Sie deren Abbruch mit pg_cancel_backend. Das beendet nicht unbedingt die Sitzung und gibt keine untätige Verbindung frei. Zum Freigeben einer geprüften Sitzung kann pg_terminate_backend nötig sein; dabei kann eine offene Transaktion zurückgerollt werden. Klären Sie vorher Zuständigkeit, Unterbrechungsfolgen und Wiederholungsverhalten. Alle Sitzungen pauschal zu schließen ist kein Rettungsplan.

Das Ende des Vorfalls bestimmen

Testen Sie eine echte Anwendungsanfrage, bestätigen Sie weniger Fehler und stabile Verbindungszahlen und starten Sie Aufgaben schrittweise wieder. Füllt sich die Kapazität schnell erneut, bleibt die Ursache aktiv. Danach empfehle ich ein Budget je Dienst, begrenzte Pools, klare Verantwortung und angemessene Wiederholungsabstände.

Die entscheidende Maßnahme: Zuerst die Verbindungserzeugung regeln, statt lediglich den Behälter zu vergrößern.

Technische Quellen: PostgreSQL / Connections · PostgreSQL / Statistics · PostgreSQL / Administration.