Referenztabelle der Instanzparameter

Eine Instanzklasse als Satz von Parameterwerten lesen

Eine Instanzklasse sieht aus wie eine Angabe aus zwei Spalten — so viele vCPU, so viel Speicher — ist aber in Wahrheit ein Bündel bereits getroffener Entscheidungen. Allein die Speichergröße legt die Verbindungsobergrenze, den Puffer-Cache und das Weltbild des Planers fest. Diese Tabelle zeigt jede Instanz neben den Parameterwerten, die ihr Speicher impliziert, damit Sie eine Klasse als die Konfiguration lesen können, die sie tatsächlich ist.

So wird gerechnet

• Listet jede Instanzklasse im Katalog der gewählten Cloud, von der kleinsten zur größten.
• Zeigt Speicher je vCPU — der schnellste Weg, eine Allzweckklasse von einer speicheroptimierten zu unterscheiden.
• Nennt max_connections je Instanz, berechnet aus der veröffentlichten Regel des Anbieters und der gewählten Engine.
• Zeigt shared_buffers oder innodb_buffer_pool_size sowie effective_cache_size, abgeleitet aus den RDS-Standardausdrücken.

Spalten und ihre Herkunft
  vCPU, Speicher   die Instanzklassentabelle des Anbieters
  GiB / vCPU       Speicher geteilt durch vCPU
  max_connections  die veroeffentlichte Regel fuer die gewaehlte Engine
  shared_buffers        25% des Speichers  (PostgreSQL)
  innodb_buffer_pool    75% des Speichers  (MySQL)
  effective_cache_size  75% des Speichers  (Planer-Hinweis)

Rechenbeispiel

Eine Instanzklasse, db.m5.2xlarge mit 8 vCPU und 32 GiB, auf beiden Engines gelesen.

1. Speicher je vCPU = 32 ÷ 8 = 4 GiB, das Allzweckverhältnis
2. PostgreSQL: rund 3.324 Verbindungen, shared_buffers 8 GiB, effective_cache_size 24 GiB
3. MySQL: rund 2.518 Verbindungen, innodb_buffer_pool_size 24 GiB
4. dieselbe Hardware, zwei Engines — und die Pufferzuteilung unterscheidet sich um den Faktor drei

PostgreSQL behält 25% für sich und überlässt den Rest dem Seiten-Cache des Betriebssystems; MySQL beansprucht 75% für InnoDB, weil es sich auf diesen Cache nicht stützt. Beides ist keine beiläufige Tuning-Entscheidung, sondern Folge der Klassenwahl — und der Grund, warum dieselbe Instanz unter beiden Engines anders arbeitet.

Das Ergebnis lesen

• Speicher je vCPU verrät, wofür eine Klasse gedacht ist. Rund 2 GiB je vCPU ist rechenorientiert, 4 GiB Allzweck, 8 GiB und mehr speicheroptimiert — AWS' r-Klassen, Azures E-Serie. Für eine Datenbank sind die höheren Verhältnisse meist das bessere Geschäft, denn Speicher kauft zugleich Cache und Verbindungsreserve.
• Azures B1ms ist die eine Zeile, die dem eigenen Muster nicht folgt: 50 Verbindungen, wo die Regel je GiB weit mehr erwarten ließe. Diese Tabelle gibt die veröffentlichten Azure-Werte wieder, statt eine Kurve anzupassen, sodass die Anomalie erhalten bleibt.
• Die t-Klasse bei AWS und die B-Serie bei Azure sind burstfähig. Sie sammeln im Leerlauf CPU-Guthaben und drosseln, sobald es aufgebraucht ist — hervorragend für Entwicklung, schlecht für gleichmäßige Produktionslast. Die Tabelle zeigt ihre Ausstattung, nicht diesen Vorbehalt, also behalten Sie ihn im Kopf.
• Die Cloud-SQL-Einträge sind gängige benutzerdefinierte Zuschnitte, kein vollständiger Katalog, denn Cloud SQL erlaubt nahezu jede Kombination aus vCPU und Speicher. Lesen Sie diese Spalte als repräsentativ.
• Diese Parameterwerte sind die Standardwerte einer Instanz, keine Grenzen. Alle drei Clouds erlauben ein Überschreiben per Parametergruppe oder Flag, und gerade die Verbindungsformeln sind nur Standardwerte — was ihre Änderung kostet, zeigt der Rechner für maximale Verbindungen.

Häufige Fragen

Warum ändert sich max_connections beim Wechsel der Engine?

Weil jede Engine einen eigenen Divisor in der Anbieterformel hat. Bei AWS teilt PostgreSQL den verfügbaren Speicher durch etwa 9,5 MB je Verbindung, MySQL durch etwa 12,6 MB — dieselbe Instanz ergibt also weniger MySQL-Verbindungen. MariaDB verwendet ab 10.5 wiederum einen anderen Divisor.

Ist mehr Speicher je vCPU für eine Datenbank immer besser?

Meist ja, bis der Arbeitsdatensatz in den Speicher passt. Sind die von Abfragen berührten Daten erst einmal im Cache, kauft zusätzlicher Speicher keine Geschwindigkeit mehr, sondern nur noch Verbindungsreserve. Bei kleinem Datenbestand und CPU-lastigen Abfragen — viel Sortieren, Aggregieren, JSON-Verarbeitung — kann ein niedrigeres Verhältnis mit mehr Kernen die bessere Instanz sein.

Kann ich diese Werte nach dem Start ändern?

Ja — über eine Parametergruppe bei RDS, Serverparameter bei Azure oder Datenbank-Flags bei Cloud SQL. Manche wirken sofort, manche erfordern einen Neustart: shared_buffers und innodb_buffer_pool_size werden beim Start zugeteilt und gehören zur zweiten Gruppe. Die hier gezeigten Standardwerte sind sinnvolle Ausgangspunkte und verdienen einen Grund, bevor man sie überschreibt.

Quellen

• Amazon RDS — DB-Instanzklassen
• Azure Database for PostgreSQL — Limits
• Cloud SQL for PostgreSQL — Flags