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 Postgre SQL
Der folgende Abschnitt behandelt die Verwaltung der Leistung und Skalierung für einen Amazon Aurora SQL Postgre-DB-Cluster. Es umfasst auch Informationen über andere Wartungsaufgaben.
Themen
- Skalierung von Aurora SQL Postgre-DB-Instances
- Maximale Anzahl an Verbindungen zu einer Aurora SQL Postgre-DB-Instance
- Temporäre Speicherlimits für Aurora Postgre SQL
- Riesige Seiten für Aurora Postgre SQL
- 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
- Temporäre Dateien mit Postgre verwalten SQL
Skalierung von Aurora SQL Postgre-DB-Instances
Sie können Aurora SQL Postgre-DB-Instances auf zwei Arten skalieren: Instance-Skalierung und Leseskalierung. Weitere Informationen zur Lese-Skalierung finden Sie unter Skalierung von Lesevorgängen.
Sie können Ihren Aurora SQL Postgre-DB-Cluster skalieren, indem Sie die DB-Instance-Klasse für jede DB-Instance im DB-Cluster ändern. Aurora Postgre SQL 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 Spezifikationen der von Aurora Postgre unterstützten DB-Instance-Klassen finden Sie SQL unterUnterstützte DB-Engines für DB-Instance-Klassen.
Maximale Anzahl an Verbindungen zu einer Aurora SQL Postgre-DB-Instance
Ein Aurora SQL Postgre-DB-Cluster weist Ressourcen auf der Grundlage der DB-Instance-Klasse und ihres verfügbaren Speichers zu. Jede Verbindung zum 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 Verbindung im Leerlauf 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 durch Postgre-Verbindungen im Leerlauf verbraucht werden. SQL
Die maximale Anzahl von Verbindungen, die eine Aurora SQL Postgre-DB-Instance zulässt, wird durch den max_connections Parameterwert bestimmt, der in der Parametergruppe für diese DB-Instance angegeben ist. 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 zu unterstützende Verbindungen AWS Automatisierung. Vor dem Ändern des Parameters max_connections sollten Sie Folgendes berücksichtigen:
-
Wenn der
max_connectionsWert zu niedrig ist, verfügt die Aurora SQL Postgre-DB-Instance möglicherweise nicht über genügend 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 SQL LEAST Postgre-Funktion 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.
Tipp
Wenn Ihre Anwendungen häufig Verbindungen öffnen und schließen oder eine große Anzahl langlebiger Verbindungen offen halten, empfehlen wir Ihnen, Amazon RDS Proxy zu verwenden. RDSProxy ist ein vollständig verwalteter, hochverfügbarer Datenbank-Proxy, der mithilfe von Verbindungspooling Datenbankverbindungen sicher und effizient gemeinsam nutzt. Weitere Informationen zu RDS Proxy finden Sie unterAmazon RDS Proxy für Aurora verwenden.
Einzelheiten dazu finden Sie Aurora Serverless v2 Instanzen verarbeiten diesen Parameter, sieheMaximale Anzahl der Verbindungen für Aurora Serverless v2.
Temporäre Speicherlimits für Aurora Postgre SQL
Aurora Postgre SQL speichert Tabellen und Indizes im Aurora-Speichersubsystem. Aurora Postgre SQL 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 SQL Postgre-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 Postgre SQL mit Aurora Optimized Reads.
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 SQL Postgre-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.
| 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
NVMeMit aktivierten Instance-Typen kann der verfügbare temporäre Speicherplatz bis zur NVMe Gesamtgröße erhöht werden. Weitere Informationen finden Sie unter Verbesserung der Abfrageleistung für Aurora Postgre SQL mit Aurora Optimized Reads.
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 eine Operation verfügbaren Speicher zu erhöhen, erhöhen Sie die Werte der Postgre-Parameter work_mem oder maintenance_work_mem
Riesige Seiten für Aurora Postgre SQL
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 SQL Postgre-Funktion wird von allen derzeit verfügbaren Aurora Postgre-Versionen unterstützt. SQL
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. Sie können den huge_pages Parameterwert nicht ändern oder diese Funktion in den unterstützten Instanzklassen von Aurora Postgre SQL deaktivieren.
