Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Leistung und Skalierung für Amazon Aurora PostgreSQL

Im folgenden Abschnitt werden die Verwaltung der Performance und Skalierung für einen Amazon-Aurora-PostgreSQL-DB-Cluster erläutert. Es umfasst auch Informationen über andere Wartungsaufgaben.

Skalierung von Aurora PostgreSQL-DB-Instances

Sie können Aurora PostgreSQL-DB-Instances auf zwei Arten skalieren, durch Skalierung der Instance oder durch Skalierung der Lesevorgänge. Weitere Informationen zur Lese-Skalierung finden Sie unter Skalierung von Lesevorgängen.

Sie können Ihr Aurora-PostgreSQL-DB-Cluster skalieren, indem Sie die DB-Instance-Klasse für jede DB-Instance im DB-Cluster ändern. Aurora PostgreSQL unterstützt mehrere DB-Instance-Klassen, die für Aurora optimiert sind. Verwenden Sie nicht die Instance-Klasse db.t2 oder db.t3 für größere Aurora-Cluster mit einer Größe von mehr als 40 Terabyte (TB).

Die Skalierung erfolgt nicht augenblicklich. Es kann 15 Minuten oder länger dauern, bis die Änderung zu einer anderen DB-Instance-Klasse abgeschlossen ist. Wenn Sie diesen Ansatz zum Ändern der DB-Instance-Klasse verwenden, sollten Sie die Änderung während des nächsten geplanten Wartungsfensters (und nicht sofort) anwenden, um Auswirkungen auf die Benutzer zu vermeiden.

Alternativ zur direkten Änderung der DB-Instance-Klasse können Sie Ausfallzeiten minimieren, indem Sie die Hochverfügbarkeitsfunktionen von Amazon Aurora verwenden. Fügen Sie Ihrem Cluster zuerst ein Aurora-Replikat hinzu. Wählen Sie beim Erstellen des Replikats die DB-Instance-Klassengröße, die Sie für Ihren Cluster verwenden möchten. Wenn das Aurora Replica mit dem Cluster synchronisiert wird, können Sie das neu hinzugefügte Replikat ausfallen. Weitere Informationen hierzu finden Sie unter Aurora-Replikate und Schnelles Failover mit Amazon Aurora PostgreSQL.

Detaillierte Angaben zu den von Aurora PostgreSQL unterstützten DB-Instance-Klassen finden Sie unter Unterstützte DB-Engines für DB-Instance-Klassen.

Maximale Verbindungen zu einer Aurora PostgreSQL-DB-Instance

Ein Aurora-PostgreSQL-DB-Cluster weist Ressourcen basierend auf der DB-Instance-Klasse und ihrem verfügbaren Speicher zu. Jede Verbindung mit dem DB-Cluster verbraucht inkrementelle Mengen dieser Ressourcen wie Speicher und CPU. Der pro Verbindung verbrauchte Speicher variiert je nach Abfragetyp, Anzahl und der Tatsache, ob temporäre Tabellen verwendet werden. Selbst eine inaktive Verbindung verbraucht Speicher und CPU. Das liegt daran, dass bei Abfragen für eine Verbindung mehr Speicher für jede Abfrage zugewiesen wird und der Speicher nicht vollständig freigegeben wird, auch wenn die Verarbeitung beendet wird. Daher empfehlen wir Ihnen, sicherzustellen, dass Ihre Anwendungen keine inaktiven Verbindungen aufrechterhalten: Jede dieser Verbindungen verschwendet Ressourcen und wirkt sich negativ auf die Leistung aus. Weitere Informationen finden Sie unter Ressourcen, die von inaktiven PostgreSQL-Verbindungen verbraucht werden.

Die maximale Anzahl der zulässigen Verbindungen einer Aurora-PostgreSQL-DB-Instance wird durch den Wert des Parameters max_connections in der Parametergruppe für diese DB-Instance festgelegt. Die ideale Einstellung für den max_connections Parameter ist eine Einstellung, die alle Client-Verbindungen unterstützt, die Ihre Anwendung benötigt, ohne zu viele ungenutzte Verbindungen, plus mindestens 3 weitere Verbindungen zur Unterstützung AWS der Automatisierung. Vor dem Ändern des Parameters max_connections sollten Sie Folgendes berücksichtigen:

Der Standardwert von max_connections wird von der folgenden Aurora-PostgreSQL–FunktionLEAST abgeleitet:

LEAST({DBInstanceClassMemory/9531392},5000).

Wenn Sie den Wert für max_connections ändern möchten, müssen Sie eine benutzerdefinierte DB-Cluster-Parametergruppe erstellen und dort ihren Wert ändern. Wenn Sie Ihre benutzerdefinierte DB-Parametergruppe auf Ihren Cluster angewendet haben, müssen Sie die primäre Instance neu starten, damit der neue Wert wirksam wird. Weitere Informationen erhalten Sie unter Amazon-Aurora-PostgreSQL-Parameter und Eine DB-Cluster-Parametergruppe in Amazon Aurora erstellen.

Nähere Informationen darüber, wie Aurora Serverless v2 Instanzen verarbeiten diesen Parameter, sieheMaximale Anzahl der Verbindungen für Aurora Serverless v2.

Temporäre Speicherlimits für Aurora PostgreSQL

Aurora PostgreSQL speichert Tabellen und Indizes im Aurora-Speichersubsystem. Aurora PostgreSQL verwendet separaten temporären Speicher für nicht persistente temporäre Dateien. Dazu gehören Dateien, die für Zwecke wie das Sortieren großer Datensätze während der Abfrageverarbeitung oder für Indexerstellungsvorgänge verwendet werden. Weitere Informationen finden Sie im Artikel Wie kann ich lokale Speicherprobleme in Aurora-PostgreSQL-kompatiblen Instances beheben?.

Diese lokalen Speicher-Volumes werden von Amazon Elastic Block Store gestützt und können durch Einsatz einer größeren DB-Instance-Klasse erweitert werden. Weitere Informationen über Speicher finden Sie unter Amazon Aurora Aurora-Speicher. Sie können Ihren lokalen Speicher für temporäre Objekte auch vergrößern, indem Sie einen NVMe aktivierten Instance-Typ und Aurora Optimized Reads-fähige temporäre Objekte verwenden. Weitere Informationen finden Sie unter Verbesserung der Abfrageleistung für Aurora PostgreSQL mit Aurora-optimierten Lesevorgängen.

Die folgende Tabelle zeigt die maximale Menge an temporärem Speicher, die für jede Aurora PostgreSQL-DB-Instance-Klasse verfügbar ist. Informationen zur Unterstützung der DB-Instance-Klasse für Aurora finden Sie unter Amazon Aurora Aurora-DB-Instance-Klassen.

Sie können den für eine DB-Instance verfügbaren temporären Speicher mit der FreeLocalStorage CloudWatch Metrik --> überwachen, die unter beschrieben ist CloudWatch Amazon-Metriken für Amazon Aurora. (Dies gilt nicht für Aurora Serverless v2.)

Bei einigen Workloads können Sie die Menge an temporärem Speicher reduzieren, indem Sie den Prozessen, die die Operation ausführen, mehr Arbeitsspeicher zuweisen. Um den für einen Vorgang verfügbaren Speicher zu erhöhen, erhöhen Sie die PostgreSQL-Werte der Parameter work_mem oder maintenance_work_mem.

Huge Pages für PostgreSQL

Huge Pages ist eine Arbeitsspeicher-Verwaltungsfunktion, die den Overhead reduziert, wenn eine DB-Instance mit großen, zusammenhängenden Arbeitsspeicherblöcken arbeitet, wie sie von gemeinsam genutzten Puffern verwendet werden. Diese PostgreSQL-Funktion wird von allen derzeit verfügbaren Versionen von Aurora PostgreSQL unterstützt.

Der Parameter Huge_pages ist standardmäßig für alle DB-Instance-Klassen aktiviert, außer t3.medium, db.t3.large, db.t4g.medium, db.t4g.large. In den unterstützten Instance-Klassen von Aurora PostgreSQL können Sie den Parameterwert huge_pages nicht ändern oder diese Funktion deaktivieren.

Auf Aurora PostgreSQL-DB-Instances, die die Speicherfunktion für riesige Seiten nicht unterstützen, kann die Speichernutzung bestimmter Prozesse steigen, ohne dass sich die Arbeitslast entsprechend ändert.

Das System weist beim Serverstart gemeinsam genutzte Speichersegmente wie den Puffercache zu. Wenn große Speicherseiten nicht verfügbar sind, berechnet das System diese Zuweisungen nicht dem Postmaster-Prozess. Stattdessen bezieht es den Speicher in den Prozess mit ein, der zuerst auf jede 4-KB-Seite im gemeinsamen Speichersegment zugegriffen hat.