Die Datenbank lehnt Verbindungen ab. Wie groß sollten Anwendungspools sein?
Warum zusätzliche Backend-Prozesse die verfügbaren Datenbankverbindungen ausschöpfen können. Pool-Budgets, wartende Anfragen und ein vorsichtiges Vorgehen bei PostgreSQL.
Beim Skalieren eines Backends kann ein Problem entstehen, das ein CPU-Diagramm nicht erklärt: Die Anwendung wartet auf eine Datenbankverbindung oder PostgreSQL lehnt neue Verbindungen ab. Jeder Prozess kann einen eigenen Pool verwalten, also Verbindungen zur Wiederverwendung bereithalten. Bewerten Sie dessen Grenze zusammen mit allen anderen Datenbankclients. Das folgende Vorgehen bezieht sich auf PostgreSQL 18; die Beispiele für Clientmetriken verwenden node-postgres.
Ermitteln Sie, wo die Anfrage wartet
Unterscheiden Sie Wartezeiten im Anwendungspool von einem Fehler beim Aufbau einer neuen Verbindung zum Server. Beobachten Sie in node-postgres waitingCount zusammen mit totalCount und idleCount. Eine wachsende Warteschlange ist ein Anlass zu prüfen, wer Verbindungen wie lange hält. Messen Sie die Abfragedauer getrennt von der Zeit, die das Anfordern einer Verbindung benötigt.
Prüfen Sie in PostgreSQL die Einstellung mit SHOW max_connections; und die reservierten Verbindungsplätze. Eine Erhöhung dieses Limits erfordert einen Serverneustart und erhöht bestimmte Ressourcenzuweisungen, darunter gemeinsamen Speicher. Ermitteln Sie während eines Vorfalls zuerst die tatsächliche Ursache des Drucks und die Möglichkeiten für einen kontrollierten Eingriff.
Zählen Sie die Pools aller Prozesse zusammen
Addieren Sie bei direkten Datenbankverbindungen die maximalen Poolgrößen aller Prozesse. Berücksichtigen Sie Worker, geplante Jobs und weitere Dienste. Ein Rechenbeispiel: Vier Prozesse mit jeweils höchstens 20 Verbindungen können insgesamt bis zu 80 Verbindungen öffnen. Das ist eine Kapazitätsrechnung, keine Messung eines bestimmten Systems und keine Empfehlung für die Poolgröße.
Berücksichtigen Sie im Budget auch die vorübergehend parallel laufende alte und neue Version beim Deployment sowie die Obergrenze der automatischen Skalierung. Lassen Sie Platz für Administration und Diagnose. Wählen Sie die Grenze eines Prozesses anhand dieses Budgets und anhand von Lastmessungen; ein Webdienst und eine Stapelverarbeitung können unterschiedliche Einstellungen benötigen.
Untersuchen Sie lange gehaltene Verbindungen
Vergleichen Sie in pg_stat_activity application_name, Zustand und Transaktionsbeginn. Idle bedeutet, dass die Sitzung auf einen neuen Befehl wartet. Idle in transaction bezeichnet eine offene Transaktion ohne gerade laufende Abfrage und sollte untersucht werden. Einige Diagnosedetails zu fremden Sitzungen erfordern entsprechende Berechtigungen; ein fehlender Wert beweist nicht, dass kein Problem besteht.
Wenn Sie einen Client in node-postgres manuell anfordern, sorgen Sie auch nach einem Fehler für seine Rückgabe an den Pool, etwa mit finally. Konfigurieren Sie außerdem eine begrenzte Wartezeit beim Anfordern einer Verbindung. Falls Sie eine bestimmte Datenbanksitzung beenden müssen, prüfen Sie vorher Zuständigkeit und Auswirkungen; pg_terminate_backend beendet die gesamte Sitzung. Verbindungen ohne Analyse pauschal zu beenden ist ein schlechter erster Eingriff.
Prüfen Sie die Änderung bei realistischem Parallelbetrieb
Wenn Sie PgBouncer verwenden, unterscheiden Sie Clientverbindungen von Verbindungen zu PostgreSQL. Der Parameter default_pool_size legt die Standardgrenze je Kombination aus Benutzer und Datenbank fest; bewerten Sie bei mehreren Kombinationen und Instanzen deren gemeinsame Grenzen. Transaction Pooling gibt die Serververbindung nach einer Transaktion zurück, erfordert aber Kompatibilitätsprüfungen der Anwendung, etwa bei LISTEN oder sitzungsgebundenen Sperren.
Testen Sie in einer getrennten Umgebung Spitzenlast und parallel laufende Versionen beim Deployment. Vergleichen Sie Verbindungswartezeiten, Fehlerzahlen und die Antwortzeit der Benutzeraktion. Beobachten Sie nach einer Produktionsänderung dieselben Werte und bereiten Sie die Rückkehr zur vorherigen Konfiguration vor. Eine niedrigere Verbindungszahl allein zeigt noch nicht, ob Clients das Ergebnis rechtzeitig erhalten.
- Unterscheiden Sie Warten im Pool von einer Ablehnung durch die Datenbank.
- Berücksichtigen Sie alle Prozesse und parallele Versionen beim Deployment.
- Prüfen Sie die Rückgabe von Clients und lange offene Transaktionen.
- Messen Sie Fehler und Antwortzeiten nach der Konfigurationsänderung.
Was Sie mitnehmen
Planen Sie Anwendungspools als gemeinsames Budget für Datenbankverbindungen. Ermitteln Sie bei ausgeschöpfter Kapazität die Prozesse und Operationen, die Verbindungen halten, und testen Sie die Änderung anschließend beim erwarteten Parallelbetrieb.
