Verbindungen und Pooling
Die wichtigsten Befehle zum Merken
SHOW POOLS— Clients, Serververbindungen und wartende Arbeit untersuchen.SHOW STATS— Transaktions- und Abfragestatistik prüfen.
Befehle und Optionen
| Befehl oder Option | Bedeutung |
|---|---|
psql -X |
Ohne psql-Startdateien verbinden. |
-h localhost -p 6432 |
Den vorhandenen lokalen Pooler wählen. |
-d pgbouncer |
Seine virtuelle Administrationsdatenbank öffnen. |
-c 'SHOW POOLS;' |
Diesen Prüfbefehl ausführen und beenden. |
-c 'SHOW STATS;' |
Statistik lesen und beenden. |
Diese SHOW-Befehle gehören zu PgBouncer, nicht zu gewöhnlichem PostgreSQL-SQL. Die Anmeldung nutzt das konfigurierte Testkonto. Ausgabefelder variieren nach Version; orientiere dich an Namen statt festen Spaltenpositionen.
Die entscheidenden Konzepte
1. Eine Verbindung ist mehr als ein Socket
Eine Datenbankverbindung benötigt Transportaufbau, Authentifizierung und serverseitigen Zustand. Für jede kleine Abfrage neu zu verbinden erzeugt vermeidbaren Aufwand.
Ein Verbindungspool hält wiederverwendbare Verbindungen und leiht sie Aufrufern. Anwendungen können lokal poolen; ein Proxy wie PgBouncer kann viele Clients auf weniger Datenbankverbindungen verteilen. Grenzen dieser getrennten Schichten müssen zusammen betrachtet werden.
2. Ein voller Pool lässt Anfragen warten
Ein begrenzter Pool kann nicht beliebig viele Verbindungen ausgeben. Ist seine Kapazität belegt, warten Aufrufer, erreichen Zeitgrenzen oder werden gemäß Richtlinie abgewiesen.
Ursachen können zu viel Parallelität, langsame Abfragen oder lange Transaktionen sein. Ein größerer Pool kann die Warteschlange lediglich in die Datenbank verschieben und Konkurrenz verstärken. Ziel ist passende Parallelität, nicht die höchstmögliche Verbindungszahl.
3. Der Poolmodus bestimmt den mitgeführten Zustand
Session-Pooling ordnet einer Clientsitzung eine Serververbindung zu. Transaction-Pooling gibt sie nach jeder Transaktion zurück, sodass andere Clients sie verwenden können.
Damit ändern sich Annahmen zu Sitzungszustand. Temporäre Objekte, Sitzungseinstellungen und weitere Funktionen benötigen Kompatibilitätsprüfung für Modus und Version. Auch Prepared Statements hängen von Implementierung und Konfiguration ab. Funktionierendes SELECT beweist nicht die Verträglichkeit aller Sitzungsfunktionen.
4. Wartezeit und Ausführungszeit getrennt messen
Eine langsame Anfrage kann vor Beginn der Datenbankabfrage auf einen Poolplatz warten. Die reine Ausführungszeit unterschätzt dann die vom Benutzer erlebte Dauer.
Betrachte wartende Clients, Serverzustände, Transaktionsdauer und Anfragelatenz gemeinsam. Aggregierte Statistiken können einzelne lange Wartezeiten verbergen. Mehrere Momentaufnahmen zeigen Bewegung; Zähler allein erklären aber keine einzelne langsame Anfrage.
Ein kleines Beispiel
Optional: Untersuche den vorhandenen autorisierten Pooler. Die Befehle lesen Verwaltungsansichten und ändern weder Limits noch Dienste oder Anwendungsdaten.
psql -X -h localhost -p 6432 -d pgbouncer -c 'SHOW POOLS;'
psql -X -h localhost -p 6432 -d pgbouncer -c 'SHOW STATS;'Vergleiche bei SHOW POOLS cl_waiting mit sv_active, sv_idle und pool_mode. maxwait nennt, falls vorhanden, die älteste aktuelle Clientwartezeit in Sekunden; ergänzende Bruchteilsfelder sind möglich.
SHOW STATS trennt Gesamtzähler und jüngere Durchschnittsfelder. Zeiten wie avg_query_time verwenden Mikrosekunden. Prüfe Namen, bevor du Millisekunden oder Summen annimmst. Ein untätiges Labor kann null zeigen: eine gültige Momentaufnahme, kein Kapazitätsbenchmark. Beide Verbindungen schließen nach dem Befehl.
Merke dir: Ein Pool verwendet knappe Datenbankverbindungen erneut. Größe und Modus bestimmen Warteort und gültige Sitzungsannahmen.