Traffic-Spitze: Zweihundert aktive PHP-FPM-Prozesse, jeder öffnet eine neue Verbindung zur Datenbank. PostgreSQL erreicht sein Limit von einhundert Verbindungen – zu viele Verbindungen. Panik: Wir erhöhen das Limit auf fünfhundert. Der Datenbankspeicher explodiert, das System schaltet auf Festplatte um, die Leistung verschlechtert sich.
PgBouncer kommt: zweihundert Anwendungsclients, dreißig echte PostgreSQL-Verbindungen. Die Krise schien gelöst – bis dreißig gleichzeitige langsame Anfragen den gesamten Pool für dreißig Sekunden blockierten. Der Antrag läuft massenhaft ab. Der Pool hat die Verbindungsobergrenze ausgeblendet, nicht die Gleichzeitige Verarbeitungskapazität der Datenbank.
Verbindungspooling beseitigt offene Kosten. Es löst keine vollständigen Tabellenscans auf. Schlecht angepasst fügt es eine unsichtbare Warteschlange vor einer bereits erstickten Basis hinzu.
Wo soll der Pool im Stapel platziert werden?
Abhängig von Ihrer Umgebung ändert sich das Tool. Das Prinzip bleibt dasselbe: eine Schicht zwischen den Anwendungsprozessen und der Basis.
| Stapel | Gemeinsames Werkzeug |
|---|---|
| PHP / Python / Node → PostgreSQL | PgBouncer vor PostgreSQL |
| MySQL | ProxySQL, MariaDB MaxScale oder Anwendungspool |
| Serverlose Funktionen | Obligatorischer Pooler (verwalteter Proxy) |
| PHP ohne Pooler | Dauerhafte Verbindungen – Risiko von Zombie-Verbindungen |
Typische Architektur:
[PHP-FPM × N] → [PgBouncer:6432] → [PostgreSQL:5432]
**Verdoppeln Sie die Anwendung und den PgBouncer nicht, ohne die Kette zu verstehen – verschachtelte Pools erzeugen Latenz und Deadlocks.
Dimensionierung: Beginnen Sie mit der Basis, nicht mit der Anwendung
Für PostgreSQL wird die optimale Anzahl aktiver Verbindungen unter realer Last gemessen – nicht in einer theoretischen Tabelle. In der Praxis ist für ein KMU oft eine „default_pool_size“ zwischen zwanzig und fünfzig ausreichend; „max_client_conn“ muss die Summe der Anwendungsprozesse abdecken.
| Symptom | Wahrscheinliche Ursache |
|---|---|
| Dateipool-Zeitüberschreitung | Pool zu klein oder Abfragen zu lang |
| Niedriger Basisprozessor, App-Timeouts | Durch Sperren blockierte Abfragen |
| „Zu viele Verbindungen“ | Pool-Bypass oder Fehlkonfiguration |
Transaktionsmodus: Vorteile und Fallstricke
Beim Transaktionspooling wird die PostgreSQL-Verbindung nach der Validierung wiederverwendet. Verwenden Sie diesen Modus nicht mit sitzungsgebundenen vorbereiteten Abfragen, dauerhaften Sitzungsvariablen oder Funktionen wie Abhören und Benachrichtigung. Der Sitzungsmodus ist sicherer zu migrieren. Transaktionsmodus nach Prüfung Ihrer Datenzugriffsschicht.
Beim MySQL-Shared-Hosting sind die Verbindungen oft auf zehn oder dreißig beschränkt: Ein anwendungsseitiger Pool ist obligatorisch. In verwaltetem PostgreSQL ist manchmal ein Pooler enthalten – überprüfen Sie Ihre Angebotsgrenzen und messen Sie die Warteschlange, bevor Sie die Hardware skalieren.
In der Praxis verschwinden die meisten „Pool“-Vorfälle nach der Optimierung langsamer Abfragen: fehlende Indizes, ungefilterte Joins, zu lange Transaktionen. Der Pool wird dann zu einem nützlichen Stoßdämpfer und nicht zu einer gläsernen Decke.
Der Gipfel: Der Pool verschiebt die Sättigung
Korrekturreihenfolge: langsame Abfragen → Pool → Basisskala. Wenn Sie die Bestellung umkehren, müssen Sie für das gleiche Ergebnis mehr Warteschlange und Hardware bezahlen.
Entscheide dich und gehe ohne blinden Fleck voran
Messen Sie die Anzahl der PostgreSQL- oder MySQL-Verbindungen zum aktuellen Spitzenwert vor jeglichen Änderungen. Stellen Sie PgBouncer oder ProxySQL bereit, wenn Ihre Anwendungsprozesse einen sicheren „max_connections“ deutlich überschreiten. Legen Sie die Poolgröße basierend auf der tatsächlichen Kapazität der Datenbank fest, nicht auf der Anzahl der Worker. Überwachen wartende Kunden und durchschnittliche Wartezeit. Analysieren Sie die schwersten Abfragen parallel – siehe EXPLAIN PostgreSQL und PHP-FPM-Sättigung.
Häufig gestellte Fragen
Warum PostgreSQL bündeln?
Jede Verbindung verbraucht Speicher; Der Pool multiplext Hunderte von Anwendungsprozessen über weniger Serververbindungen.
Sitzung vs. Transaktionsmodus PgBouncer?
Der Transaktionsmodus ist effizienter; Der Sitzungsmodus bleibt besser mit objektrelationalen Mapping-Tools kompatibel.
Wie dimensioniere ich pool_size?
Beginnen Sie mit der Basisprozessorkapazität und messen Sie sie unter realer Auslastung, nicht anhand der Anzahl der Anwendungsarbeiter.
Überschreibt der Pool den SQL-Index?
Nein – langsame Abfragen bleiben langsam, sobald eine Verbindung hergestellt ist. Optimieren Sie zuerst die Abfragen.
Der Verbindungspool kümmert sich um die Öffnung – nicht um die Abfrage, die die Datenbank verstopft, sobald die Verbindung hergestellt ist.