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.
Verwalten von 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.
Themen
- Skalierung von Aurora PostgreSQL-DB-Instances
- Maximale Verbindungen zu einer Aurora PostgreSQL-DB-Instance
- Temporäre Speicherlimits für Aurora PostgreSQL
- Huge Pages für PostgreSQL
- Testen von Amazon Aurora PostgreSQL unter Verwendung von Fehlersimulationsabfragen
- Anzeigen des Volume-Status für einen Aurora PostgreSQL-DB-Cluster
- RAM-Datenträger für das stats_temp_directory
- Verwalten temporärer Dateien mit PostgreSQL
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).
Anmerkung
Wir empfehlen, die T-DB-Instance-Klassen nur für Entwicklungs- und Testserver oder andere Nicht-Produktionsserver zu verwenden. Weitere Einzelheiten zu den T-Instance-Klassen finden Sie unter DB-Instance-Klassenarten.
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, die alle Client-Verbindungen unterstützt, die Ihre Anwendung benötigt, ohne zu viele ungenutzte Verbindungen, plus mindestens 3 weitere Verbindungen zur Unterstützung der AWS Automatisierung. Vor dem Ändern des Parameters max_connections sollten Sie Folgendes berücksichtigen:
-
Wenn der Wert von
max_connectionszu niedrig ist, verfügt die Aurora-PostgreSQL-DB-Instance möglicherweise nicht über ausreichende Verbindungen, wenn Clients versuchen, eine Verbindung herzustellen. In diesem Fall werden durch Verbindungsversuche mitpsqlFehlermeldungen wie die folgenden ausgelöst:psql: FATAL: remaining connection slots are reserved for non-replication superuser connections -
Wenn der Wert von
max_connectionsdie Anzahl der benötigten Verbindungen übersteigt, können die nicht verwendeten Verbindungen die Leistung beeinträchtigen.
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 finden Sie unter Amazon-Aurora-PostgreSQL-Parameter und Erstellen einer DB-Cluster-Parametergruppe.
Tipp
Wenn Ihre Anwendungen häufig Verbindungen öffnen und schließen oder langlebige Verbindungen in großer Zahl offen lassen, empfehlen wir Ihnen, Amazon-RDS-Proxy zu verwenden. RDS-Proxy ist ein vollständig verwalteter, hochverfügbarer Datenbank-Proxy, der Datenbankverbindungen sicher und effizient per Verbindungspooling freigibt. Weitere Informationen zu RDS Proxy finden Sie unter Verwenden von Amazon RDS Proxy für Aurora.
Weitere Informationen dazu, wie Aurora Serverless v2-Instances diesen Parameter behandeln, finden Sie unter Maximale 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-Speicher und -Zuverlässigkeit. Sie können Ihren lokalen Speicher für temporäre Objekte auch vergrößern, indem Sie einen NVMe-fähigen 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.
Anmerkung
Beim Skalieren von DB-Instances, z. B. von db.r5.2xlarge auf db.r5.4xlarge, treten unter Umständen storage-optimization-Ereignisse auf.
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 Aurora DB-Instance-Klassen.
| DB-Instance-Klasse | Maximal verfügbarer temporärer Speicher (GiB) |
|---|---|
| db.x2g.16xlarge | 1829 |
| db.x2g.12xlarge | 1606 |
| db.x2g.8xlarge | 1071 |
| db.x2g.4xlarge | 535 |
| db.x2g.2xlarge | 268 |
| db.x2g.xlarge | 134 |
| db.x2g.large | 67 |
| db.r7g.16xlarge | 1008 |
| db.r7g.12xlarge | 756 |
| db.r7g.8xlarge | 504 |
| db.r7g.4xlarge | 252 |
| db.r7g.2xlarge | 126 |
| db.r7g.xlarge | 63 |
| db.r7g.large | 32 |
| db.r6g.16xlarge | 1008 |
| db.r6g.12xlarge | 756 |
| db.r6g.8xlarge | 504 |
| db.r6g.4xlarge | 252 |
| db.r6g.2xlarge | 126 |
| db.r6g.xlarge | 63 |
| db.r6g.large | 32 |
| db.r6i.32xlarge | 1829 |
| db.r6i.24xlarge | 1500 |
| db.r6i.16xlarge | 1008 |
| db.r6i.12xlarge | 748 |
| db.r6i.8xlarge | 504 |
| db.r6i.4xlarge | 249 |
| db.r6i.2xlarge | 124 |
| db.r6i.xlarge | 62 |
| db.r6i.large | 31 |
| db.r5.24xlarge | 1500 |
| db.r5.16xlarge | 1008 |
| db.r5.12xlarge | 748 |
| db.r5.8xlarge | 504 |
| db.r5.4xlarge | 249 |
| db.r5.2xlarge | 124 |
| db.r5.xlarge | 62 |
| db.r5.large | 31 |
| db.r4.16xlarge | 960 |
| db.r4.8xlarge | 480 |
| db.r4.4xlarge | 240 |
| db.r4.2xlarge | 120 |
| db.r4.xlarge | 60 |
| db.r4.large | 30 |
| db.t4g.large | 16,5 |
| db.t4g.medium | 8,13 |
| db.t3.large | 16 |
| db.t3.medium | 7,5 |
Anmerkung
NVMe-fähige Instanztypen können den verfügbaren temporären Speicherplatz um bis zur gesamten NVMe-Größe erhöhen. Weitere Informationen finden Sie unter Verbesserung der Abfrageleistung für Aurora PostgreSQL mit Aurora-optimierten Lesevorgängen.
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
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.
