Wie kann man die PostgreSQL-Diskrepanz zwischen der Empfehlung des Verbindungspools ((2 * n_cores) + n_disks) und der Unterstützung von Hunderten von Verbindungen verstehen?

Aus PostgreSQL-Dokumenten:

• Anzahl der Datenbankverbindungen -> So ermitteln Sie die optimale Größe des Datenbankverbindungspools

  Für einen optimalen Durchsatz sollte die Anzahl der aktiven Verbindungen in der Nähe von ((core_count * 2) + effektive_spindle_count) liegen.

• Optimieren Ihres PostgreSQL-Servers -> max_connections

  Im Allgemeinen kann PostgreSQL auf guter Hardware einige hundert Verbindungen unterstützen.

Für mich - keinen erfahrenen DBA - gibt es hier irgendwo eine Diskrepanz, insbesondere was die Angebote einiger DB-as-a-Service-Anbieter betrifft.

Zu diesem Zeitpunkt verfügt der größte Computer von Amazon RDS (db.r3.8xlarge) beispielsweise über 32 vCPUs, die nach der ersten Formel bei vielen Festplatten mit 100 Verbindungen im Pool möglicherweise optimal ausgeführt werden können. Würde es mit den "paar hundert Verbindungen" aus der zweiten Formel nicht sehr schlecht laufen?

Noch extremer ist die Diskrepanz für einen anderen DBaaS-Anbieter, der einen 2-Core-Server mit 500 gleichzeitigen Verbindungen vorschlägt. Wie könnte das möglicherweise gut funktionieren?

Wenn ich etwas falsch verstehe, lass es mich wissen. Danke vielmals!

"Kann unterstützen"! = "Optimaler Durchsatz".

Sie können viele Verbindungen verwenden, aber es ist langsamer.

Wenn Sie weniger Verbindungen und Warteschlangen verwenden, wird derselbe Arbeitsaufwand in kürzerer Zeit erledigt.

Noch extremer ist die Diskrepanz für einen anderen DBaaS-Anbieter, der einen 2-Core-Server mit 500 gleichzeitigen Verbindungen vorschlägt. Wie könnte das möglicherweise gut funktionieren?

Entweder verwenden sie ein Verbindungspooling-Frontend wie PgBouncer im Transaktionspooling-Modus, oder es funktioniert nicht gut.

Die Leute mögen große Zahlen, also geben sie dir große Zahlen.

Sie beeinträchtigen tatsächlich die Leistung, indem sie dies tun. PostgreSQL hat einige Kosten, die linear skaliert max_connectionswerden. Selbst wenn die Verbindungen nicht verwendet werden, hat dies dennoch Auswirkungen auf die Leistung.

Darüber hinaus verursachen selbst inaktive Verbindungen weitere Reinigungskosten.

Wenn die Verbindungen aktiv funktionieren, haben Sie auch Konflikte mit Systemressourcen und internen Sperren.

Ich stoße routinemäßig auf Leute, die PostgreSQL-Leistungsprobleme haben - und die versuchen, diese zu lösen, indem sie mehr Verbindungen, mehr Mitarbeiter in ihre Anwendung usw. einfügen. Insbesondere Leute, die Warteschlangensysteme ausführen. Es ist überraschend schwer, sie davon zu überzeugen, dass eine Verringerung der Anzahl der Mitarbeiter das System schneller macht und dass ihre ursprünglichen Leistungsprobleme darauf zurückzuführen sind, dass überhaupt zu viele Mitarbeiter vorhanden sind .

Viele Anwendungen haben eine schlechte Verbindungsdisziplin und halten Verbindungen offen, auch wenn sie nicht verwendet werden.

Das Festlegen eines hohen Verbindungslimits ist eine günstige Versicherung gegen diese Anwendungen. Bis sich etwas ändert und die Anwendungen entscheiden, alle diese Verbindungen aktiv zu nutzen, wird die Versicherung ziemlich teuer.

Eine wichtige Unterscheidung zwischen den beiden in der Frage verglichenen Ansprüchen besteht darin, dass die erste eine grobe Formulierung für die Anzahl der aktiven Verbindungen gleichzeitig ist. Der zweite Anspruch bezieht sich auf die Einstellung, die Sie für das maximal zulässige Maß festgelegt haben, das Postgres akzeptiert. Dies sind zwei getrennte Dinge.

Wenn Sie zurückgehen und den Artikel Optimale Größe des Datenbankverbindungspools lesen , werden Sie feststellen, dass Sie Ihr aktives Verbindungspooling auf der Clientseite und nicht auf der Serverseite festlegen. Sie schlagen außerdem vor, dass Sie in Ihrem Wert für max_connections genügend Kapazität belassen , um feste Verbindungen zu berücksichtigen , z. B. praktische Clientaktivitäten und administrative Aktivitäten. Sie nicht möchten , dass Ihre max_connections auf das aktive Verbindungslimit Ihrer Mitarbeiter einzustellen oder Sie könnten nicht in der Lage sein zu psql in , wenn Sie benötigen!