Auf welche Connection-Pool-Grösse relativ zur Anzahl CPU-Kerne haben sich Teams bei einem PostgreSQL-Server eingependelt, und welche Messung hat sie zu einer Änderung bewogen?

Offene Frage

Die PostgreSQL-Dokumentation beschreibt max_connections als die maximale Anzahl gleichzeitiger Verbindungen zum Server, mit einem Standardwert, der typischerweise 100 beträgt. Die PostgreSQL-Wiki-Seite zur Anzahl der Datenbankverbindungen gibt eine Faustregel für optimalen Durchsatz an, die die Anzahl aktiver Verbindungen bei ungefähr dem Zweifachen der Kernzahl plus der effektiven Spindelzahl ansetzt, und argumentiert, dass mehr Verbindungen als das den Durchsatz eher senken als steigern. Zwischen beidem steht der Pool: ein In-Process-Pool pro Anwendungsinstanz, ein externer Pooler wie PgBouncer, oder beides, und die Pool-Grösse ist die Zahl, an der Teams tatsächlich drehen.

Das Wiki hält nicht fest, worauf diese Zahl hinausläuft, nachdem ein Team sie an einer echten Arbeitslast getunt hat. Landen Teams in der Nähe der Formel, oder eine Grössenordnung darüber, weil jede von zwanzig Anwendungsinstanzen auf ihrem eigenen Pool von zehn besteht? Was geschah mit der Latenz auf Seiten der Anwendung, als der Pool verkleinert wurde: stauten sich Anfragen am Pool und liefen in ein Timeout, oder wurde die Datenbank schneller, weil weniger Transaktionen um Locks und CPU konkurrierten? Verbesserte sich etwas, als er vergrössert wurde, oder verschob die Änderung das Warten nur vom Pool zur Datenbank? Welche Messung war entscheidend: Pool-Wartezeit, Zustände in pg_stat_activity, Lock-Waits, CPU-Sättigung auf dem Datenbankhost, oder ein Latenz-Perzentil am Rand? Und unterscheidet sich die Antwort zwischen kurzen OLTP-Transaktionen, langen analytischen Abfragen und Arbeitslasten mit im Leerlauf befindlichen Idle-in-Transaction-Sitzungen?

Die Frage ist wichtig, weil die Formel häufig zitiert und selten überprüft wird, und weil die Pool-Grösse mit Instanzzahl, Transaktionsdauer und dem eigenen Modus des Poolers auf eine Weise zusammenwirkt, die eine Faustregel nicht erfassen kann.

Was eine nützliche Antwort enthält

Kernzahl und Speicher des Datenbankhosts, die Anzahl der Anwendungsinstanzen, der Pooler und sein Modus (Session, Transaction) sowie der Charakter der Arbeitslast (Verteilung der Transaktionsdauer, Anteil der Idle-in-Transaction-Zeit). Die Pool-Grösse vor und nach jeder Änderung, mit Datum. Die Messung, die die Änderung ausgelöst hat, und die Messung, die sie beurteilt hat: Pool-Wartezeit und ihre Perzentile, Datenbank-CPU, Anzahl der Lock-Waits, Latenz-Perzentile der Anfragen, Fehlerraten durch Pool-Erschöpfung. Ob auch max_connections geändert wurde. Berichte, in denen die Formel zutraf, Berichte, in denen sie weit danebenlag, und Berichte, in denen sich zeigte, dass die Pool-Grösse weniger ausmachte als die Transaktionsdauer, sind alle nützlich, sofern die Zahlen mit ihrer Quelle und dem beobachteten Zeitraum angegeben werden.