Verbindungspool-Rechner

Einen Verbindungspool für das Deployment auslegen, nicht für den Durchschnitt

Verbindungspools versagen selten unter gleichmäßiger Last. Sie versagen beim Deployment, wenn die alten Pods noch nicht heruntergefahren sind und die neuen ihre Pools bereits geöffnet haben — der Bedarf verdoppelt sich kurzzeitig. Dieses Werkzeug rechnet aus, was Ihre Flotte der Datenbank tatsächlich abverlangt, im Ruhezustand und in genau diesem Moment, und vergleicht beides mit dem durchgesetzten Limit.

So wird gerechnet

• Multipliziert Anwendungsinstanzen mit der Poolgröße — das ist die Zahl, die die Datenbank sieht, nicht die konfigurierte Poolgröße.
• Zieht die für Replikation und Überwachung reservierten Verbindungen ab, damit Sie gegen das wirklich Verfügbare vergleichen.
• Verdoppelt den Bedarf, um ein rollierendes Deployment abzubilden, wenn alte und neue Instanzen gleichzeitig Pools halten.
• Kennzeichnet drei Zustände: über dem Limit, so knapp dass ein Deployment es sprengt, und komfortabel.

nutzbar        = max_connections - reserviert
dauerhaft      = Instanzen x Pool_je_Instanz
waehrend_deploy = dauerhaft x 2

sicher, wenn waehrend_deploy <= nutzbar

Rechenbeispiel

Ein Dienst auf 40 Pods mit je einem Pool von 20, gegen eine Instanz mit 500 Verbindungen, davon 15 reserviert.

1. nutzbar = 500 - 15 = 485
2. dauerhaft = 40 x 20 = 800 — bereits 165% des Limits
3. Reserve = 485 - 800 = -315, Verbindungen werden also schon jetzt abgewiesen
4. Pool halbieren auf 10: dauerhaft = 400, also 82% — im Ruhezustand passt es
5. aber beim Deployment: 400 x 2 = 800, weiterhin 165%, Deployments scheitern also weiter
6. Pool von 6: dauerhaft = 240 (49%), Deployment = 480 gegen 485 — es passt knapp

Der Pool, der ein Deployment übersteht, ist ein Drittel so groß wie der, der nur den Durchschnitt übersteht. Zwischen Schritt zwei und sechs hat sich am Verkehr nichts geändert — nur die Pooleinstellung und die Bereitschaft, für den schlimmsten statt für den typischen Moment auszulegen.

Das Ergebnis lesen

• Ein Pool von 6 je Pod klingt klein und ist es nicht. HikariCPs eigene Empfehlung lautet, dass kleine Pools große schlagen: Ein Pool braucht nur genug Verbindungen, um die Kerne der Datenbank auszulasten, und kurzes Warten in der Anwendung ist billiger als Warten in der Datenbank. Einige Verbindungen je Kern über die gesamte Flotte sind das Ziel.
• Rechnen Sie jeden Prozess mit, der einen Pool öffnet, nicht nur die Web-Ebene. Hintergrund-Worker, Cron-Jobs, Migrationsläufe, Admin-Konsolen und Ihre eigene psql-Sitzung schöpfen aus derselben Obergrenze — und das sind die Verbindungen, die niemand zählt, bis die Grenze erreicht ist.
• Die hier angenommene Verdopplung ist der Normalfall eines rollierenden Deployments mit Readiness-Prüfung. Ein Deployment, das alles auf einmal ersetzt, kann höher ausschlagen; eines, das Pod für Pod ersetzt, kaum. Passen Sie die Instanzzahl an, wenn Ihre Strategie abweicht.
• Serverlose und autoskalierende Lasten brechen diese Rechnung vollständig, weil die Instanzzahl nicht in Ihrer Hand liegt. Genau diesen Fall löst ein Proxy — RDS Proxy, PgBouncer, Cloud SQL Auth Proxy — indem er viele Client-Verbindungen auf wenige Datenbankverbindungen multiplext.
• Leerlaufende Verbindungen sind nicht kostenlos. In PostgreSQL ist jede ein Prozess, der Speicher hält; in MySQL trägt jede Puffer je Thread. Ein großzügiger Pool, der meist untätig ist, kostet Sie trotzdem den reservierten Speicher.

Häufige Fragen

Warum den Bedarf fürs Deployment verdoppeln?

Weil ein rollierendes Deployment absichtlich überlappt. Die neue Instanz muss starten, ihren Pool öffnen und die Readiness-Prüfung bestehen, bevor die alte geleert wird — in diesem Fenster halten beide volle Pools. Ersetzt Ihre Plattform Instanzen einzeln, ist die Überlappung kleiner, der Fehlermodus aber derselbe und prüfenswert.

Mein Pool liegt weit unter dem Limit und ich sehe trotzdem Verbindungsfehler. Warum?

Meist etwas außerhalb des Pools. Suchen Sie nach Workern, geplanten Jobs und Einzelskripten mit eigenen Verbindungen, nach einer während des Deployments laufenden Migration und nach Verbindungen, die Code nicht zurückgibt. Der Pool ist nur der Teil des Bedarfs, den Sie konfiguriert haben.

Ist ein größerer Pool schneller?

Ab einem Punkt nein — er ist langsamer. Sobald jeder Datenbankkern beschäftigt ist, bringen mehr gleichzeitige Verbindungen Kontextwechsel und Sperrkonkurrenz statt Durchsatz. Die messbare Folge eines überdimensionierten Pools ist meist schlechtere Tail-Latenz, nicht besserer Durchsatz.

Wo passt ein Pooler wie PgBouncer hinein?

Zwischen die beiden Zahlen. Er lässt eine große, schwankende Zahl von Client-Verbindungen eine kleine, feste Zahl von Datenbankverbindungen teilen — genau das, was dieses Werkzeug bei hoher oder unvorhersehbarer Instanzzahl anzeigt. Im Transaction-Pooling-Modus gibt er Verbindungen zudem zwischen Anweisungen frei, statt sie für die Sitzung zu halten.