Rechner für maximale Datenbankverbindungen

Wie viele Verbindungen eine verwaltete Datenbank tatsächlich zulässt

Jede verwaltete Datenbank hat eine Verbindungsobergrenze, und keine der drei großen Clouds legt sie gleich fest. AWS leitet sie über eine Formel aus dem Instanzspeicher ab, Azure veröffentlicht je Produkt eine feste Tabelle, und Google Cloud SQL arbeitet mit Speicherstufen, die sprunghaft steigen. Dieses Werkzeug wendet die jeweils veröffentlichte Regel an, damit Sie die reale Obergrenze kennen, bevor Sie einen Pool um eine Vermutung herum bauen.

So wird gerechnet

• Wendet die dokumentierte Regel des Anbieters auf die gewählte Instanz an, keine Faustregel.
• Zeigt Formelergebnis und realistisches Ergebnis nebeneinander, denn DBInstanceClassMemory ist kleiner als der RAM der Instanz.
• Vergleicht alle drei Clouds bei gleichem Speicher — dort werden die Unterschiede unübersehbar.
• Zieht die Verbindungen ab, die Azure für Replikation und Überwachung reserviert, sodass die gezeigte Zahl die für Ihre Anwendung nutzbare ist.

AWS RDS, aus den dokumentierten Standardparametern
  PostgreSQL   LEAST({DBInstanceClassMemory/9531392}, 5000)
  MySQL        {DBInstanceClassMemory/12582880}
  MariaDB 10.5+ LEAST({DBInstanceClassMemory/25165760}, 12000)

Azure Flexible Server
  veröffentlichte Tabelle je Produkt, etwa 107 je GiB, gedeckelt bei 5000
  abzüglich 15 für Replikation und Überwachung

Google Cloud SQL
  veroeffentlichte Speicherbaender, untere Grenze inklusive
  3,75-6 GiB -> 100   6-7,5 -> 200    7,5-15 -> 400
  15-30      -> 500  30-60  -> 600   60-120 -> 800
  120+       -> 1000

Rechenbeispiel

Eine db.r7g.xlarge mit PostgreSQL — 4 vCPU und 32 GiB Speicher — und was dieselben 32 GiB anderswo bringen.

1. 32 GiB = 34.359.738.368 Byte
2. 34.359.738.368 / 9.531.392 = 3.604 — die Antwort der Formel
3. die Deckelung bei 5.000 greift in dieser Größe nicht, also bleibt es bei 3.604
4. aber DBInstanceClassMemory ist nicht der RAM der Instanz: RDS zieht zuerst Betriebssystem und eigene Prozesse ab
5. mit dem von AWS dokumentierten Overhead ergeben sich in der Praxis rund 3.324
6. Azure bei 32 GiB: 3.437 gesamt, 3.422 nutzbar nach den 15 reservierten
7. Google Cloud SQL bei 32 GiB: 600, weil 32 in das Band 30 bis 60 GiB fällt

Identische Hardware — und Cloud SQL gibt Ihnen ein Fünftel dessen, was die beiden anderen geben. Wer einen Dienst zwischen Clouds verschiebt, scheitert eher an dieser einen Zahl als an irgendetwas im Schema.

Das Ergebnis lesen

• DBInstanceClassMemory ist nicht der Speicher auf dem Datenblatt. RDS reserviert Speicher für das Betriebssystem und eigene Verwaltungsprozesse und rechnet die Formel über den Rest. AWS dokumentiert die Lücke mit einem Beispiel: Eine 8-GiB-Instanz liefert etwa 630 Verbindungen, während die naive Division 683 ergibt. Das sind rund 8% weniger, und das gilt in jeder Größe.
• Google Cloud SQL verwendet veröffentlichte Bänder statt einer Formel, die Grenze steigt also nicht gleichmäßig mit dem Speicher — innerhalb eines Bandes steigt sie gar nicht. Jede Instanz von 30 GiB bis knapp unter 60 GiB erhält dieselben 600 Verbindungen; eine Verdopplung des Speichers innerhalb eines Bandes bringt nichts, der gesamte Zuwachs fällt auf die Grenze.
• Azure behandelt B1ms als Sonderfall mit 50 Verbindungen, außerhalb des sonst konsistenten Musters je GiB. Deshalb gibt dieses Werkzeug die Azure-Tabelle wörtlich wieder, statt eine Gerade hindurchzulegen.
• Das sind Standardwerte, keine harten Grenzen. max_connections ist in allen drei Clouds ein änderbarer Parameter. Ihn anzuheben ist meist die falsche Lösung, denn jede Verbindung kostet Speicher und einen Prozess — genau deshalb hängt der Standard überhaupt am Speicher.
• Ein Verbindungslimit ist kein Nebenläufigkeitsziel. Postgres wird mit mehr Verbindungen nicht schneller; jenseits von etwa dem Mehrfachen der Kernzahl bedeuten mehr Verbindungen mehr Kontextwechsel und weniger Durchsatz. Nutzen Sie einen Pooler und halten Sie den Pool deutlich unter der Grenze.

Häufige Fragen

Warum meldet meine Instanz ein anderes max_connections?

Drei häufige Gründe. Die Parametergruppe wurde womöglich geändert, dann überschreibt Ihr Wert die Formel vollständig. Die Engine-Version zählt — MariaDB hat den Divisor in 10.5 geändert. Und bei AWS verschiebt sich die Zahl leicht mit dem tatsächlich gemeldeten Hostspeicher, weshalb dieses Werkzeug beide Werte zeigt.

Soll ich max_connections einfach anheben?

Meist nicht. Jede PostgreSQL-Verbindung ist ein eigener Prozess mit eigenem Speicher, jede MySQL-Verbindung trägt Puffer je Thread. Die Grenze anzuheben verlagert den Ausfall von abgewiesenen Verbindungen, die sichtbar und behebbar sind, hin zu Speicherdruck und OOM-Killer, die beides nicht sind. Ein Verbindungspooler ist fast immer die bessere Antwort.

Hat ein Read Replica dasselbe Limit?

Es hat das Limit seiner eigenen Instanzklasse, oft dasselbe, weil Replikate meist der Primärinstanz entsprechen. Die Verbindungen des Replikats zählen aber getrennt, sodass die Umleitung von Lesezugriffen tatsächlich Reserve auf der Primärinstanz schafft und das Problem nicht nur verschiebt.

Warum liegt Cloud SQL so viel niedriger?

Google bemisst den Standard danach, was die Instanz gut bedienen kann, nicht danach, was sie technisch annimmt, und erwartet verbindungsintensive Lasten hinter einem Pooler. Die Zahl ist eine Designentscheidung, keine Hardwaregrenze — durchgesetzt wird sie trotzdem.

Quellen

• Amazon RDS — Kontingente und Beschränkungen
• Amazon RDS — DB-Instanzklassen
• Azure Database for PostgreSQL — Limits
• Cloud SQL for PostgreSQL — Flags