Verwaltetes Verbindungs-Pooling – Übersicht

Mit verwaltetem Verbindungs-Pooling können Sie Ihre Arbeitslasten skalieren, indem Sie die Ressourcennutzung und die Verbindungs-Latenz für Ihre Cloud SQL-Instanzen optimieren. PostgreSQL erstellt für jede Verbindung einen neuen Prozess, was zu Arbeitsspeichernutzung und Verbindungsaufbau-Aufwand führt. In Architekturen, in denen häufig viele kurzlebige Verbindungen hergestellt werden, z. B. bei Microservices oder serverlosen Anwendungen, die in Cloud Run ausgeführt werden, kann sich dieser Mehraufwand auf die Datenbankleistung und ‑skalierbarkeit auswirken.

Wenn Managed Connection Pooling aktiviert ist, stellen Clients eine Verbindung zu einem Zwischenverbindungspool-Cluster her, anstatt direkt zum Datenbankserver. Diese dynamische Zuweisung führt zu Leistungsverbesserungen, insbesondere bei skalierten Verbindungen, da plötzliche Verbindungsspitzen abgefangen und vorhandene Datenbankverbindungen wiederverwendet werden.

Verbindungspooler und Verbindungspools

Wenn Clientanwendungen eine Verbindung zu einer Instanz mit aktiviertem verwaltetem Verbindungs-Pooling herstellen, stellen sie eine Verbindung zu einem Zwischenverbindungspool-Cluster her, anstatt direkt zum Datenbankserver. Der Verbindungspool-Cluster besteht aus einem oder mehreren Verbindungspoolern. Ein Connection Pooler ist ein Datenbankproxydienst, der Datenbankverbindungen zwischen Clientanwendungen und dem Datenbankserver verwaltet und weiterleitet.

Ein Connection Pooler verwaltet Verbindungspools als Gruppe offener, wiederverwendbarer Datenbankserververbindungen pro Datenbank- und Nutzerpaar.

Wenn eine authentifizierte Clientanwendung als bestimmter Nutzer eine Verbindung zu einer Datenbank herstellt, leitet der Connection Pooler die Anfrage an den entsprechenden Verbindungspool weiter:

  • Wenn im Pool eine inaktive Serververbindung verfügbar ist, weist der Connection Pooler sie der Clientanfrage zu.
  • Wenn keine inaktive Serververbindung verfügbar ist und das Poollimit (max_pool_size) noch nicht erreicht wurde, erstellt der Verbindungspooler eine neue Serververbindung im Pool.
  • Wenn alle Serververbindungen im Pool verwendet werden und das Poollimit erreicht ist, wechselt der Client in einen Wartezustand, bis eine Serververbindung verfügbar wird.
  • Wenn die Anfrage abgeschlossen ist, wird die Serververbindung zur Wiederverwendung an den Verbindungspool zurückgegeben.

Beziehung zwischen Poolern und Pools

Ein einzelner Connection Pooler kann mehrere Verbindungspools gleichzeitig verwalten. Für jedes eindeutige Datenbank- und Datenbanknutzerpaar, das über diesen Pooler eine Verbindung herstellt, gibt es einen Pool.

Wenn auf Ihrer Instanz mehrere Verbindungspooler ausgeführt werden, verwaltet jeder Verbindungspooler unabhängig eine eigene Gruppe von Verbindungspools für die Datenbank- und Nutzerpaare, die an ihn weitergeleitet werden.

Leistung und Skalierbarkeit des verwalteten Verbindungs-Poolings sind auf mehreren Ebenen verfügbar:

  • Skalierung des Verbindungspool-Clusters:Die Anzahl der Verbindungspooler im Cluster wird automatisch basierend auf der Anzahl der für die Instanz bereitgestellten vCPU-Kerne skaliert (die Anzahl der vCPUs wird durch 4 geteilt, mit einem Minimum von 1 Verbindungspooler). So wird verhindert, dass das Verbindungs-Pooling zu einem Engpass wird. Eingehende Clientverbindungen werden auf die verfügbaren Connection Pooler verteilt. Beispiel:

    • Auf einer Instanz mit 2 oder 4 vCPUs wird ein Verbindungspooler ausgeführt.
    • Auf einer Instanz mit 8 vCPUs werden 2 Connection Pooler ausgeführt.
    • Auf einer Instanz mit 16 vCPUs werden 4 Verbindungspooler ausgeführt.
    • Auf einer Instanz mit 32 vCPUs werden 8 Verbindungspooler ausgeführt.
    • Auf einer Instanz mit 64 vCPUs werden 16 Verbindungspooler ausgeführt.

  • Pooler und Poolskalierung:Da Verbindungs-Pooler unabhängig voneinander arbeiten, werden alle Konfigurationsoptionen pro Verbindungs-Pooler und nicht global für die Instanz angewendet. Serververbindungen werden nach Bedarf bis zu einem von max_pool_size definierten Höchstwert für jeden verwalteten Pool in jedem Connection Pooler erstellt. Wenn max_pool_size beispielsweise auf 50 für eine Instanz mit 2 Verbindungspoolern (8 vCPUs) festgelegt ist, kann jeder Verbindungspooler bis zu 50 Serververbindungen für ein bestimmtes Datenbank- und Nutzerpaar öffnen. Das ergibt insgesamt bis zu 100 Serververbindungen für diesen Pool auf der Instanz. Die richtige Poolgröße ist entscheidend für die Leistung: Wenn Sie diesen Wert zu niedrig festlegen, kann dies zu längeren Wartezeiten für Verbindungen führen. Wenn Sie ihn zu hoch festlegen, können Datenbankserverressourcen verschwendet werden.

  • Clientverbindungskonfigurationen:Clientverbindungslimits und Timeout-Verhalten werden ebenfalls pro Verbindungspooler konfiguriert. Zu den wichtigsten Parametern gehören:

    • max_client_connections: Beschränkt die maximale Anzahl von Clientverbindungen,die pro Verbindungspooler zulässig sind. Der Standardwert ist 5.000 Verbindungen pro Verbindungspooler.
    • client_connection_idle_timeout: Steuert die Dauer, die eine Clientverbindung inaktiv bleiben kann, bevor sie das Zeitlimit überschreitet.
    • query_wait_timeout: Steuert die Dauer, die eine Abfrage auf eine verfügbare Serververbindung im Pool wartet, bevor es zu einer Zeitüberschreitung kommt.

Anwendungsfälle und Überlegungen

Beachten Sie bei der Verwendung des verwalteten Verbindungs-Poolings Folgendes:

  • Sie können verwaltetes Verbindungs-Pooling für jede transaktionale Arbeitslast verwenden. Es bietet jedoch den größten Durchsatz- und Latenzvorteil für Anwendungen mit kurzlebigen Verbindungen oder für Anwendungen, bei denen es zu einem plötzlichen Anstieg der Verbindungen kommt.
  • Bei langlebigen Verbindungen kann die Verbindungsleistung mit verwaltetem Verbindungs-Pooling etwas geringer sein als bei einer direkten Verbindung. In diesem Fall bietet das verwaltete Verbindungs-Pooling eine Verbindungsskalierung, wenn die Anzahl der Verbindungen sehr hoch ist. Bei Anwendungen, die in der Regel langlebige Verbindungen herstellen, sollten Sie jedoch möglicherweise kein Connection Pooling verwenden.
  • Mit Identity and Access Management können Sie Verbindungen zu Ihrer Instanz sichern, je nachdem, welcher Port vom verwalteten Verbindungspooling verwendet wird. Weitere Informationen zur Funktionsweise von IAM in Cloud SQL und zu den Einschränkungen finden Sie unter IAM-Authentifizierung.

Weitere Informationen zum Aktivieren des verwalteten Verbindungs-Poolings finden Sie unter Verwaltetes Verbindungs-Pooling konfigurieren.

Voraussetzungen

Damit Sie das verwaltete Verbindungs-Pooling verwenden können, muss Ihre Instanz die folgenden Anforderungen erfüllen:

  • Ihre Instanz muss eine Cloud SQL Enterprise Plus-Instanz sein.
  • Sie müssen nur über eine direkte Verbindung oder den Cloud SQL Auth-Proxy mit Ihrer Instanz verbunden sein.
  • Ihre Instanz muss für den Zugriff auf private Dienste eingerichtet sein, eine öffentliche IP-Adresse verwenden oder eine neue Instanz mit aktiviertem Private Service Connect sein.
  • Ihre Instanz muss die neue Cloud SQL-Netzwerkarchitektur verwenden.
  • Für verwaltetes Verbindungs-Pooling ist eine Mindestwartungsversionsnummer von POSTGRES_$version.R20250727.00_14 erforderlich. Weitere Informationen zur Self-Service-Wartung finden Sie unter Self-Service-Wartung durchführen.

Pooling-Optionen

Mit dem verwalteten Verbindungs-Pooling können Sie mithilfe des Parameters pool_mode verwalten, wie Verbindungen gepoolt werden. Sie haben die folgenden Pooling-Optionen:

  • transaction (Standard): Verbindungen werden auf Transaktionsebene zusammengefasst. Verbindungen werden nach Abschluss jeder Transaktion an den Pool zurückgegeben. Cloud SQL empfiehlt die Verwendung des Pooling-Modus transaction für kurzlebige Verbindungen.
  • session: Verbindungen werden auf Sitzungsebene zusammengefasst. Für jede Sitzung wird eine dedizierte Serververbindung verwendet, die einen Sitzungsstatus beibehält. Dadurch wird die Pooling-Effizienz verringert. Wenn ein Client die Verbindung trennt, wird die Serververbindung wieder in den Verbindungspool aufgenommen.

Erweiterte Konfigurationsoptionen

Sie können das verwaltete Verbindungs-Pooling anpassen, indem Sie die folgenden Konfigurationsoptionen verwenden.

Konfigurationsname Beschreibung
max_pool_size Die maximale Anzahl von Serververbindungen, die in jedem Verbindungspool für ein Datenbank- und Nutzerpaar zulässig sind. Diese Konfiguration wird pro Connection-Pooler angewendet. Legen Sie diesen Wert entsprechend Ihrer Instanzgröße und den Anforderungen an die Poolgröße fest.

Der Standardwert ist 50 Verbindungen pro Datenbank- und Nutzerpaar für jeden Verbindungspooler.
min_pool_size Die Mindestanzahl von Serververbindungen, die jederzeit in jedem Verbindungspool verfügbar sind. Diese Konfiguration wird pro Verbindungspooler angewendet. Legen Sie diesen Wert entsprechend den Anforderungen an die Instanzgröße und die Poolgröße fest.

Wenn die Anzahl der Serververbindungen kleiner als min_pool_size ist, werden mit dieser Einstellung weitere Serververbindungen zum Pool hinzugefügt. So lassen sich plötzliche Anstiege der Datenbanklast nach Inaktivitätsphasen besser bewältigen und Verbindungen sind verfügbar und einsatzbereit.

Der Standardwert ist 0 Verbindungen.
max_client_connections Die maximale Anzahl von Clientverbindungen, die pro Verbindungspooler zulässig sind, wenn verwaltetes Verbindungspooling verwendet wird. Legen Sie diesen Wert entsprechend Ihrer Instanzgröße und den Anforderungen an die Poolgröße fest.

Der Standardwert ist 5,000 Verbindungen für jeden Connection Pooler.
max_prepared_statements Die maximale Anzahl von benannten vorbereiteten Anweisungen auf Protokollebene, die pro Verbindungspooler im transaction-Pooling-Modus unterstützt werden. Legen Sie diesen Wert entsprechend den Anforderungen an die Instanzgröße und die Poolgröße fest.

Wenn Sie diese Option auf 0 setzen, wird die Unterstützung für vorbereitete Anweisungen deaktiviert. Für eine optimale Leistung sollte dieser Wert die Anzahl der häufig verwendeten vorbereiteten Anweisungen in Ihrer Datenbank überschreiten. Eine hohe Anzahl vorbereiteter Anweisungen im verwalteten Verbindungs-Pooling kann zu einer erhöhten Arbeitsspeichernutzung führen.

Der Standardwert ist 0 Anweisungen.
client_connection_idle_timeout Die Zeit, die eine Clientverbindung inaktiv bleibt, bevor sie das Zeitlimit überschreitet. Dieser Wert kann zwischen 0 und 2,147,483 Sekunden liegen. Der Standardwert ist 0 Sekunden.
server_connection_idle_timeout Die Zeit, die eine Serververbindung inaktiv bleibt, bevor sie unterbrochen wird. Dieser Wert kann zwischen 0 und 2,147,483 Sekunden liegen. Der Standardwert ist 600 Sekunden.
query_wait_timeout Die Zeit, die eine Abfrage auf eine Serververbindung in einem Pool wartet, bevor das Zeitlimit überschritten wird.

Wenn Sie diese Option auf 0 setzen, wird sie deaktiviert. Dadurch ist eine unbegrenzte Client-Warteschlange möglich. Wenn Sie diese Option aktivieren, wird verhindert, dass Verbindungen durch nicht reagierende Server aufgehalten werden.

Dieser Wert kann zwischen 0 und 2,147,483 Sekunden liegen. Der Standardwert ist 120 Sekunden.
ignore_startup_parameters Die Parameter, die ignoriert werden sollen und die standardmäßig nicht in Startpaketen für das verwaltete Verbindungs-Pooling erfasst werden.
server_lifetime Die maximale Zeit, die eine Serververbindung ungenutzt bleibt, bevor sie durch das verwaltete Verbindungs-Pooling geschlossen wird. Wenn der Wert auf 0 Sekunden festgelegt ist, wird die Verbindung sofort nach der Verwendung geschlossen.

Der Standardwert beträgt 3600 Sekunden.

Beschränkungen

Wenn Sie Managed Connection Pooling mit Ihren Cloud SQL Enterprise Plus-Instanzen verwenden, sollten Sie die folgenden Einschränkungen beachten:

  • Wenn Sie verwaltetes Verbindungs-Pooling für eine vorhandene Instanz aktivieren, wird die Datenbank neu gestartet.
  • Managed Connection Pooling kann nur mit Cloud SQL Auth-Proxy-Version 2.15.2 und höher verwendet werden.
  • Wenn Sie den Cloud SQL-Go-Connector verwenden, empfehlen wir eine Go-Mindestversion von 1.24. Wenn Sie Go-Version 1.23 oder früher verwenden, kann es bei der Verwendung des verwalteten Verbindungspools zu Leistungseinschränkungen kommen.

  • Wenn Sie verwaltetes Verbindungs-Pooling im transaction-Pooling-Modus verwenden, werden die folgenden SQL-Funktionen nicht unterstützt:

    • SET/RESET
    • LISTEN
    • WITH HOLD CURSOR
    • PREPARE/DEALLOCATE
    • PRESERVE/DELETE ROW Temporäre Tabellen
    • LOAD
    • Advisory-Sperren auf Sitzungsebene

  • Wenn Sie die asyncpg-Datenbankschnittstellenbibliothek für den Pooler für verwaltetes Verbindungs-Pooling auf Port 3307 und 6432 verwenden, müssen Sie max_prepared_statements auf einen Wert größer als 0 aktualisieren, um die Unterstützung für vorbereitete Anweisungen im Pooler für verwaltetes Verbindungs-Pooling zu aktivieren.

  • Wenn Sie Cloud SQL for PostgreSQL Version 17 verwenden, wird die Option sslnegotiation=direct nicht unterstützt.

  • Das Tracking von Client-IP-Adressen wird beim verwalteten Verbindungs-Pooling nicht unterstützt. Wenn Sie in Suchanfragen-Insights die Option Client-IP-Adressen speichern aktivieren, werden Client-IP-Adressen als local anstelle der IP-Adresse selbst angezeigt.

Von verwaltetem Verbindungs-Pooling verwendete Ports

Wenn Sie Managed Connection Pooling aktivieren, ändern sich die Ports, die von Cloud SQL-Instanzen zum Bereitstellen von Datenbanktraffic verwendet werden. Sie können Identity and Access Management verwenden, um Verbindungen je nach Port zu sichern.

Die von Managed Connection Pooling verwendeten Ports und die verfügbaren IAM-Optionen sind wie folgt:

  • TCP-Port 5432: Wird für direkte Verbindungen durch den Postgres-Datenbankserver verwendet. Dies ist die Standardportnummer für direkte Verbindungen mit dem psql-Client.

  • TCP-Port 6432: Wird für direkte Verbindungen durch den Server für verwaltete Verbindungspools verwendet. Wenn Sie über diesen Port eine Verbindung herstellen möchten, geben Sie psql -p 6432 an, wenn Sie direkt über den psql-Client eine Verbindung herstellen.

    Sie können jede IAM-Authentifizierungsoption verwenden, wenn Sie diesen Port verwenden.

  • TCP-Port 3307: Wird nur für Verbindungen über den Cloud SQL Auth-Proxy von einem Managed Connection Pooling-Server verwendet. Wenn Sie den Cloud SQL Auth-Proxy verwenden, um eine Verbindung zu Managed Connection Pooling herzustellen, wird diese Portnummer mit dem Cloud SQL Auth-Proxy-Client konfiguriert und kann nicht geändert werden.

    Sie können mit diesem Port eine beliebige IAM-Authentifizierungsoption oder die automatische IAM-Datenbankauthentifizierung verwenden.

Serververbindungen, die vom verwalteten Verbindungs-Pooling verwendet werden

Die Datenbankkonfiguration max_connections begrenzt die maximale Anzahl von Serververbindungen, die ein Pooler im verwalteten Verbindungs-Pooling verwenden kann. Cloud SQL empfiehlt, diesen Wert basierend auf den Anforderungen der Arbeitslast Ihrer Instanz und der Größe der Datenbankinstanz anzupassen. Bei Spitzenlast kann die Anzahl der Verbindungen für die Authentifizierung sehr hoch werden.

Wenn Sie den Standardwert max_pool_size von 50 Verbindungen pro Pool verwenden, empfehlen wir, mindestens 15 Serververbindungen pro CPU für verwaltetes Verbindungs-Pooling zu reservieren, wenn Sie das Flag max_connections für Ihre Datenbank festlegen. Weitere Informationen zum Flag max_connections finden Sie unter Maximale Anzahl gleichzeitiger Verbindungen. Informationen zum Ändern des max_connections-Flags für Ihre Instanz finden Sie unter Datenbank-Flags konfigurieren.

Nächste Schritte