Die Datenbank weist neue Verbindungen ab? Das Verbindungslimit ist erreicht — meist, weil eine App Verbindungen nicht schließt oder ein Pool fehlt.
Aufwand:
ca. 25 Min.
Gilt für:
PostgreSQL
Das Symptom
Eine Anwendung kann sich zeitweise nicht mehr mit PostgreSQL verbinden und meldet
FATAL: sorry, too many clients already. Oft tritt es unter Last auf, wenn viele
Anfragen zusammenkommen, oder es verschärft sich mit der Zeit, bis ein Neustart der
App kurz Abhilfe schafft — und der Fehler dann wiederkehrt.
Die „Layer 8“-Wahrheit
Jede Verbindung zu einer PostgreSQL-Datenbank ist kein kostenloses Ticket, sondern
belegt echten Speicher auf dem Server. Deshalb gibt es eine feste Obergrenze, und
wenn sie erreicht ist, verweigert die Datenbank weitere Verbindungen — ein Schutz,
damit ein einzelner überdrehender Client nicht den ganzen Server erstickt. Der Fehler
ist also die Folge, nicht die Ursache. Die eigentliche Frage lautet: Warum sind so
viele Verbindungen gleichzeitig offen, obwohl real nur wenige Anfragen laufen?
Fast immer lautet die Antwort: Eine Anwendung öffnet fleißig neue Verbindungen und
vergisst, sie wieder zu schließen — besonders tückisch sind offen gelassene
Transaktionen, die als „idle in transaction“ ewig herumhängen. Das schlichte Anheben
des Limits behandelt hier nur das Symptom und kann den Server sogar überlasten. Die
saubere Lösung ist ein Verbindungspool, der eine kleine, feste Menge Verbindungen
wiederverwendet, statt für jede Anfrage eine neue aufzumachen. Wer das Leck stopft
und poolt, sieht diesen Fehler nicht wieder — wer nur das Limit hochdreht, verschiebt
ihn nur nach hinten.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Das Limit verstehen
PostgreSQL erlaubt nur eine feste Höchstzahl gleichzeitiger Verbindungen (Standard oft 100). Ist sie erreicht, weist die Datenbank jede weitere mit „sorry, too many clients already“ ab. Jede Verbindung kostet Speicher, deshalb ist das Limit ein Schutz — die Frage ist, warum so viele Verbindungen offen sind.
2.
Die offenen Verbindungen ansehen
Nachsehen, wer gerade verbunden ist und was diese Verbindungen tun. Viele Verbindungen im Leerlauf, besonders im Zustand „idle in transaction“, deuten auf eine App, die sie nicht sauber schließt:
SELECT count(*), state FROM pg_stat_activity GROUP BY state;
3.
Verbindungslecks in der App beheben
Die häufigste Wurzel ist eine Anwendung, die für jede Anfrage eine neue Verbindung öffnet und nicht wieder freigibt. Im Code sicherstellen, dass jede Verbindung nach Gebrauch zuverlässig geschlossen und jede Transaktion beendet wird — sonst stapeln sich die Leichen.
4.
Einen Verbindungspool einsetzen
Statt für jede Anfrage eine neue Verbindung aufzubauen, sollte die App einen Verbindungspool nutzen, der eine kleine, feste Zahl von Verbindungen wiederverwendet. Bei vielen Clients oder Serverless-Umgebungen hilft zusätzlich ein vorgeschalteter Pooler wie PgBouncer.
5.
Das Limit nur bewusst erhöhen
Das maximale Verbindungslimit lässt sich anheben, aber jede Verbindung verbraucht Serverspeicher — ein zu hoher Wert kann den Server ins Wanken bringen. Das Limit nur erhöhen, wenn der Server die Ressourcen hat, und zuerst die Ursache der vielen Verbindungen beheben.
Häufige Fragen (FAQ)
?Warum sind alle Verbindungen belegt, obwohl kaum jemand die Anwendung nutzt?
Weil Verbindungen offen bleiben, die niemand mehr braucht. Wird in der Anwendung eine Verbindung nicht sauber zurückgegeben – etwa weil ein Fehler den Code vorzeitig verlässt –, bleibt sie im Zustand idle stehen und belegt einen Platz. Nach Stunden ist das Limit erschöpft, ohne dass ein einziger Nutzer aktiv wäre.
?Ist das Erhöhen von max_connections die Lösung?
Selten. Jede Verbindung kostet PostgreSQL einen eigenen Prozess und damit Arbeitsspeicher – ein hohes Limit kann die Datenbank ausbremsen statt entlasten. Der richtige Weg ist ein Verbindungspool wie PgBouncer, der wenige echte Verbindungen effizient auf viele Anfragen verteilt.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Die Sortierbibliothek des Betriebssystems hat sich geändert. PostgreSQL warnt vor einem Versions-Konflikt — Indizes auf Textspalten sind dann unbrauchbar.