Verbindungen verwalten

Verbindungen zu Ihrer Databases for PostgreSQL-Bereitstellung beanspruchen Ressourcen. Daher ist es wichtig zu berücksichtigen, wie viele Verbindungen Sie benötigen, um die Leistung Ihrer Bereitstellung zu optimieren. PostgreSQL verwendet eine Einstellung für max_connections, um die Anzahl der Verbindungen (und Ressourcen, die von Verbindungen belegt werden) zu begrenzen und so ein Runaway-Verhalten der Verbindungen zu verhindern, wenn die Ressourcen Ihrer Bereitstellung überfordert sind.

Sie können den Wert für max_connections mit Ihrem admin-Benutzer und psql überprüfen.

ibmclouddb=> SHOW max_connections;
 max_connections
-----------------
 115
(1 row)

Verbindungslimits

Bei der Einrichtung legt Databases for PostgreSQL die maximale Anzahl von Verbindungen zu Ihrer PostgreSQL-Datenbank auf 115 fest. 15 Verbindungen sind für den Superuser reserviert, um den Status und die Integrität Ihrer Datenbank zu erhalten, und für Sie und Ihre Anwendungen stehen 100 Verbindungen zur Verfügung. Wenn die Anzahl der Verbindungen zur Datenbank das Limit von 100 Verbindungen überschreitet, schlagen neue Verbindungen fehl und es wird eine Fehlermeldung ausgegeben.

FATAL: remaining connection slots are reserved for
non-replication superuser connections

Das Überschreiten des Verbindungslimits für Ihre Bereitstellung kann dazu führen, dass Ihre Datenbank von Ihren Anwendungen nicht erreicht werden kann.

Sie können die Anzahl der Verbindungen zu Ihrer Bereitstellung mit dem Benutzer "admin", psql und pg_stat_database überprüfen.

SELECT count(distinct(numbackends)) FROM pg_stat_database;

Wenn Sie herausfinden müssen, wohin die Verbindungen verlaufen, können Sie die Verbindungen nach Datenbank aufgliedern.

SELECT datname, numbackends FROM pg_stat_database;

Um die Verbindungen zu einer bestimmten Datenbank genauer zu untersuchen, fragen Sie pg_stat_activity ab.

SELECT * FROM pg_stat_activity WHERE datname='ibmclouddb';

Verbindungen beenden

Ihr Administratorbenutzer hat die Rolle pg_signal_backend. Wenn Sie Verbindungen finden, die zurückgesetzt oder geschlossen werden müssen, kann der Admin-Benutzer beides nutzen pg_cancel_backend und pg_terminate_backend. Die pid eines Prozesses wird anhand der Tabelle pg_stat_activity ermittelt.

  • pg_cancel_backend bricht die aktuelle Abfrage einer Verbindung ab, ohne die Verbindung zu beenden und ohne weitere Abfragen zu stoppen, die möglicherweise gerade ausgeführt werden.

    SELECT pg_cancel_backend(pid);
    
  • pg_terminate_backend stoppt den gesamten Prozess und schließt die Verbindung.

    SELECT pg_terminate_backend(pid);
    

Der Administratorbenutzer verfügt über die Berechtigung zum Zurücksetzen oder Schließen der Verbindungen für jeden Benutzer in der Bereitstellung mit Ausnahme der Superuser. Achten Sie darauf, dass die Replikationsverbindungen nicht vom Benutzer ibm-replication beendet werden, da dies die hohe Verfügbarkeit Ihrer Bereitstellung beeinträchtigt.

Verbindungen beenden

Wenn Ihre Bereitstellung das Verbindungslimit erreicht oder Sie Probleme bei der Verbindung zu Ihrer Bereitstellung haben und vermuten, dass eine hohe Anzahl von Verbindungen das Problem ist, trennen Sie alle Verbindungen zu Ihrer Bereitstellung.

In der Benutzerschnittstelle gibt es auf der Registerkarte Einstellungen eine Schaltfläche für End connections für Ihre Bereitstellung. Seien Sie vorsichtig, da dies alle mit Ihrer Bereitstellung verbundenen Komponenten beeinträchtigt.

Der CLI-Befehl zum Beenden von Verbindungen zur Bereitstellung lautet:

ibmcloud cdb deployment-kill-connections <DEPLOYMENT_NAME_OR_CRN>

Sie können auch die Cloud Databases API verwenden, um die Operation zum Beenden aller Verbindungen auszuführen.

Verbindungspooling

Eine Möglichkeit, das Überschreiten des Verbindungslimits zu verhindern und sicherzustellen, dass die Verbindungen von Ihren Anwendungen effizient gehandhabt werden, ist das Verbindungspooling. Wenn Sie das IBM Cloud® Databases for PostgreSQL-Verbindungslimit auf mehr als 500 Verbindungen setzen, sollten Sie ernsthaft in Erwägung ziehen, Verbindungspooling zu verwenden oder erneut zu bewerten, wie Verbindungen effizienter genutzt und verwaltet werden können. Das Performance Benchmarking in der PostgreSQL-Community empfiehlt 500 oder weniger Verbindungen für eine optimale Datenbankleistung.

Viele PostgreSQL-Treiberbibliotheken verfügen über Klassen und Funktionen für das Verbindungspooling. In der Dokumentation Ihres Treibers finden Sie Informationen darüber, wie Sie das Verbindungspooling für Ihren Anwendungsfall optimal implementieren. Beispielsweise enthält der Python-Treiber Psycopg2 Klassen zur Verwaltung des Verbindungspoolings in Ihrer Anwendung. Der Treiber Java PostgreSQL JDBC verfügt über Methoden für das Connection-Pooling sowohl auf Anwendungs- als auch auf Anwendungsserver-Ebene.

Alternativ können Sie ein Drittanbieter-Tool wie PgBouncer verwenden, um die Verbindungen Ihrer Anwendung zu verwalten. Databases for PostgreSQL-Bereitstellungen bieten integrierte Unterstützung für die Authentifizierung auth_query über PgBouncer's, sodass eine von Ihnen betriebene PgBouncer-Instanz Benutzer anhand der Datenbank validieren kann, ohne dass eine lokale Passwortliste gepflegt werden muss, und Passwortänderungen ohne einen Neustart von PgBouncer wirksam werden. Informationen zu den Einrichtungsschritten finden Sie unter Verbindungspooling mit PgBouncer.

Verbindungslimit erhöhen

PostgreSQL Weist pro Verbindung eine bestimmte Menge an Speicher zu, in der Regel etwa 5 bis 10 MB pro Verbindung. Es ist wichtig, die Gesamtspeicherkapazität zu berücksichtigen, die für Ihre Bereitstellung verfügbar ist, bevor das Verbindungslimit erhöht wird. Wenn Sie das Verbindungslimit erhöhen möchten, sollten Sie zunächst Ihre Bereitstellung skalieren, um sicherzustellen, dass genügend Speicher zur Verfügung steht, um weitere Verbindungen aufzunehmen.

Ändern Sie als Nächstes den Wert von max_connections für Ihre Bereitstellung. Um permanente Änderungen an der PostgreSQL-Konfiguration vorzunehmen, müssen Sie entweder das Cloud Databases CLI-Plug-in oder die API verwenden, um die Änderungen in die Konfigurationsdatei für Ihre Bereitstellung zu schreiben.

Um beispielsweise max_connections auf 215 zu erhöhen, kann es sinnvoll sein, Ihre Bereitstellung auf mindestens 2 GB RAM pro Datenmember zu skalieren, sodass Sie insgesamt 4 GB RAM für Ihre Bereitstellung haben. Nachdem die Skalierungsoperation abgeschlossen ist, legen Sie das Verbindungslimit fest.

  1. Bevor Sie max_connections anpassen, stellen Sie sicher, dass Sie Ihre bevorzugte Region mit einem Befehl wie diesem auswählen:
ibmcloud target -r <REGION>
  1. Erhöhen Sie anschließend die Speicherkapazität, die einer Implementierungsgruppe zur Verfügung steht, mit einem Befehl wie dem folgenden:
ibmcloud cdb deployment-groups-set deployment-example member --memory 4096
  1. Passen Sie schließlich max_connections mit einem Befehl wie dem folgenden an:
ibmcloud cdb deployment-configuration <DEPLOYMENT_NAME_OR_CRN> '{"configuration":{"max_connections":215}}'

Um die Änderungen über die API vorzunehmen, verwenden Sie den folgenden Befehl:

curl -X PATCH `https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups/member' \
-H "Authorization: Bearer $APIKEY" \
-H "Content-Type: application/json" \
-d '{"memory": {
        "allocation_mb": 4096
      }
    }'
curl -X PATCH 'https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/configuration' \
-H "Authorization: Bearer $APIKEY" \
-H "Content-Type: application/json" \
-d '{"configuration":{
        "max_connections":215
      }
    }'

Einstellungen für Verbindungslimits und TCP/IP-Keepalive

Im Falle einer Netzwerkverbindung oder eines Failovers kann es vorkommen, dass unterbrochene TCP/IP-Verbindungen in einem halb geöffneten/geschlossenen Zustand verbleiben, bis die Keepalive-Timeouts von TCP erreicht sind. Zur Vermeidung dieses Szenarios wird empfohlen, die Einstellungen socket_timeout und connection_timeout auch in Ihren speziellen Anwendungstreibern festzulegen. Die korrekten Einstellungen variieren je nach Workload und es ist wichtig, Belastungstests auszuführen, bevor Sie in die Produktion gehen. Ein guter Ausgangspunkt für die Ladezeit sind connection_timeout 2 bis 5 Sekunden. Für die ist socket_timeout eine Dauer von 30 bis 60 Sekunden ein guter Ausgangspunkt.

Außerdem werden auf der Serverseite standardmäßig die folgenden Keepalive-Konfigurationen verwendet.

  • tcp_keepalives_idle ist auf 5 Minuten gesetzt
  • tcp_keepalives_interval-Testintervall ist auf 10 Sekunden gesetzt
  • tcp_keepalives_count ist auf 6 gesetzt

Um zu verhindern, dass halboffene/geschlossene Verbindungen oder Spitzen bei Verbindungsversuchen Ihre Bereitstellung überlasten, legen Sie den Parameter max_connections für Postgres auf mindestens das Doppelte Ihrer erwarteten Verbindungsanzahl fest.

Wenn Ihr Verbindungslimit erreicht ist, können Sie sofort Alle Verbindungen beenden .