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. **Topics** + [Skalierung von Aurora PostgreSQL-DB-Instances](#AuroraPostgreSQL.Managing.Performance.InstanceScaling) + [Maximale Verbindungen zu einer Aurora PostgreSQL-DB-Instance](#AuroraPostgreSQL.Managing.MaxConnections) + [Temporäre Speicherlimits für Aurora PostgreSQL](#AuroraPostgreSQL.Managing.TempStorage) + [Huge Pages für PostgreSQL](#AuroraPostgreSQL.Managing.HugePages) + [Testen von Amazon Aurora PostgreSQL unter Verwendung von Fehlersimulationsabfragen](AuroraPostgreSQL.Managing.FaultInjectionQueries.md) + [Anzeigen des Volume-Status für einen Aurora PostgreSQL-DB-Cluster](AuroraPostgreSQL.Managing.VolumeStatus.md) + [RAM-Datenträger für das stats\$1temp\$1directory](AuroraPostgreSQL.Managing.RamDisk.md) + [Verwalten temporärer Dateien mit PostgreSQL](PostgreSQL.ManagingTempFiles.md) ## 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](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling). 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](Concepts.DBInstanceClass.Types.md). 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](Aurora.Replication.md#Aurora.Replication.Replicas) und [Schnelles Failover mit Amazon Aurora PostgreSQL](AuroraPostgreSQL.BestPractices.FastFailover.md). Detaillierte Angaben zu den von Aurora PostgreSQL unterstützten DB-Instance-Klassen finden Sie unter [Unterstützte DB-Engines für DB-Instance-Klassen](Concepts.DBInstanceClass.SupportAurora.md). ## 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](https://aws.amazon.com/blogs/database/resources-consumed-by-idle-postgresql-connections/). 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_connections` zu 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 mit `psql` Fehlermeldungen wie die folgenden ausgelöst: ``` psql: FATAL: remaining connection slots are reserved for non-replication superuser connections ``` + Wenn der Wert von `max_connections` die 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–Funktion`LEAST` 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](AuroraPostgreSQL.Reference.ParameterGroups.md) und [Eine DB-Cluster-Parametergruppe in Amazon Aurora erstellen](USER_WorkingWithParamGroups.CreatingCluster.md). **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 [Amazon RDS-Proxy für Aurora](rds-proxy.md). Weitere Informationen dazu, wie Aurora Serverless v2-Instances diesen Parameter behandeln, finden Sie unter [Maximale Anzahl der Verbindungen für Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections). ## 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?](https://repost.aws/knowledge-center/postgresql-aurora-storage-issue). 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](Aurora.Overview.StorageReliability.md). 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](AuroraPostgreSQL.optimized.reads.md). **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 [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md). | 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.r8g.48xlarge | 3072 | | db.r8g.24xlarge | 1536 | | db.r8g.16xlarge | 998 | | db.r8g.12xlarge | 749 | | db.r8g.8xlarge | 499 | | db.r8g.4xlarge | 250 | | db.r8g.2xlarge | 125 | | db.r8g.xlarge | 63 | | db.r8g.large | 31 | | 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.r7i.48xlarge | 3072 | | db.r7i.24xlarge | 1500 | | db.r7i.16xlarge | 1008 | | db.r7i.12xlarge | 748 | | db.r7i.8xlarge | 504 | | db.r7i.4xlarge | 249 | | db.r7i.2xlarge | 124 | | db.r7i.xlarge | 62 | | db.r7i.large | 31 | | 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 Mit 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 PostgreSQL mit Aurora-optimierten Lesevorgängen](AuroraPostgreSQL.optimized.reads.md). 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](Aurora.AuroraMonitoring.Metrics.md). (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\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) oder [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-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 DB-Instances von Aurora PostgreSQL, die die Arbeitsspeicherfunktion für große Seiten nicht unterstützen, kann die Speichernutzung bestimmter Prozesse zunehmen, ohne dass sich der Workload entsprechend ändert. Das System weist beim Serverstart gemeinsam genutzte Speichersegmente wie den Puffer-Cache zu. Wenn große Speicherseiten nicht verfügbar sind, belastet 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. **Anmerkung** Aktive Verbindungen teilen sich den zugewiesenen Speicher nach Bedarf, unabhängig davon, wie die Nutzung des gemeinsamen Speichers prozessübergreifend verfolgt wird. # Testen von Amazon Aurora PostgreSQL unter Verwendung von Fehlersimulationsabfragen Sie können die Fehlertoleranz Ihres Aurora PostgreSQL-DB-Clusters testen, indem Sie Fehlersimulationsabfragen verwenden. Fehlersimulationsabfragen werden als SQL-Befehle an eine Amazon Aurora-Instance ausgegeben. Mit Fehlersimulationsabfragen können Sie die Instance zum Absturz bringen, sodass Sie Failover und Wiederherstellung testen können. Sie können auch Aurora Replica-Ausfall, Festplattenausfall und Datenträgerüberlastung simulieren. Fehlersimulationsabfragen werden von allen verfügbaren Aurora-PostgreSQL-Versionen wie folgt unterstützt. + Aurora PostgreSQL 12, 13, 14 und höhere Versionen + Aurora PostgreSQL 11.7 und höhere Versionen + Aurora PostgreSQL 10.11 und höhere Versionen **Topics** + [Testen eines Instance-Ausfalls](#AuroraPostgreSQL.Managing.FaultInjectionQueries.Crash) + [Testen eines Aurora-Replikatausfalls](#AuroraPostgreSQL.Managing.FaultInjectionQueries.ReplicaFailure) + [Testen eines Festplattenausfalls](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskFailure) + [Testen einer Festplattenüberlastung](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskCongestion) Wenn eine Fehlersimulationsabfrage einen Absturz angibt, erzwingt sie einen Absturz der Aurora PostgreSQL-DB-Instance. Die anderen Fehler-Injection-Abfragen erzeugen Simulationen von Ausfallereignissen, lösen aber keine Ereignisse aus. Wenn Sie eine Fehlersimulationsabfrage senden, geben Sie auch einen Zeitraum vor, in dem die Fehlerereignissimulation ablaufen soll. Sie können eine Fehlersimulationsabfrage an eine Ihrer Aurora Replica-Instances senden, indem Sie eine Verbindung mit dem Endpunkt der Aurora Replica herstellen. Weitere Informationen finden Sie unter [Amazon-Aurora-Endpunktverbindungen](Aurora.Overview.Endpoints.md). ## Testen eines Instance-Ausfalls Sie können den Absturz einer Aurora PostgreSQL-Instance erzwingen, indem Sie die Fehlersimulationsabfrage-Funktion verwende `aurora_inject_crash()`. Für diese Fehlersimulationsabfrage tritt kein Failover auf. Wenn Sie einen Failover testen möchten, können Sie die **Failover-Instance-Aktion** für Ihren DB-Cluster in der RDS-Konsole auswählen oder den [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html) AWS CLI Befehl oder den [DBClusterFailover-RDS-API-Vorgang](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) verwenden. **Syntax** ``` 1. SELECT aurora_inject_crash ('instance' | 'dispatcher' | 'node'); ```Optionen Diese Fehlersimulationsabfrage löst einen der folgenden Ausfalltypen aus. Bei der Absturzart wird die Groß-/Kleinschreibung nicht berücksichtigt: *'instance'* Es wird ein Absturz der PostgreSQL-kompatiblen Datenbank für die Amazon Aurora-Instance simuliert. *'Disponent'* Es wird ein Absturz des Dispatchers auf primären Instance für das Aurora-DB-Cluster simuliert. Der *Dispatcher* schreibt Updates zum Cluster-Volume für ein Amazon Aurora-DB-Cluster. *'Knoten'* Es wird ein Absturz sowohl der PostgreSQL-kompatiblen Datenbank als auch des Dispatchers für die Amazon Aurora-Instance simuliert. ## Testen eines Aurora-Replikatausfalls Sie können den Ausfall eines Aurora-Replikats mittels der Fehlersimulationsabfrage-Funktion simuliere `aurora_inject_replica_failure()`. EinAurora Replikatfehler blockiert die Replikation auf dasAurora Replikat oder alle Aurora-Replikate im DB-Cluster um den angegebenen Prozentsatz für das angegebene Zeitintervall. Wenn das Zeitintervall abgeschlossen ist, sind die betroffenen Aurora-Replikate automatisch mit der primären Instance synchronisiert. **Syntax** ``` 1. SELECT aurora_inject_replica_failure( 2. percentage_of_failure, 3. time_interval, 4. 'replica_name' 5. ); ```Optionen Diese Fehlersimulationsabfrage verwendet die folgenden Parameter: *prozent\$1an\$1ausfällen* Der Prozentsatz der Replikate, die während des Ausfallereignisses blockiert werden sollen. Dieser Wert kann ein Duplikat zwischen 0 und 100 sein. Wenn Sie 0 angeben, wird keine Replikation blockiert. Wenn Sie 100 angeben, wird die gesamte Replikation blockiert. *time\$1intervall* Die Zeitspanne für die Simulation des Ausfalls des Aurora-Replikats. Das Intervall ist in Sekunden. Wenn der Wert beispielsweise 20 ist, wird die Simulation 20 Sekunden lang ausgeführt. Seien Sie vorsichtig bei der Angabe des Zeitintervalls für das Ausfallereignis in Ihrem Aurora-Replikat. Wenn Sie ein zu langes Intervall festlegen und Ihre Writer-Instance eine große Datenmenge während des Ausfallereignisses schreibt, könnte Ihr Aurora-DB-Cluster annehmen, dass Ihr Aurora-Replikat ausgefallen ist, und es ersetzen. *replica\$1name* Das Aurora-Replikat, in das die Ausfallsimulation injiziert werden soll. Geben Sie den Namen eines Aurora-Replikats an, um einen Ausfall des einzelnen Aurora-Replikats zu simulieren. Geben Sie eine leere Zeichenfolge an, um Ausfälle für alle Aurora-Replikate im DB-Cluster zu simulieren. Informationen zur Identifizierung von Replikatnamen finden Sie in der Spalte `server_id` der Funktion `aurora_replica_status()`. Zum Beispiel: ``` postgres=> SELECT server_id FROM aurora_replica_status(); ``` ## Testen eines Festplattenausfalls Sie können einen Festplattenausfall für einen Aurora PostgreSQL-DB-Cluster mittels der Fehlersimulationsabfrage-Funktion simuliere `aurora_inject_disk_failure()`. Während einer Simulation eines Festplattenausfalls markiert der Aurora PostgreSQL-DB-Cluster zufällige Festplattensegmente als fehlerhaft. Anfragen an diese Segmente werden für die Dauer der Simulation blockiert. **Syntax** ``` 1. SELECT aurora_inject_disk_failure( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval 6. ); ```Optionen Diese Fehlersimulationsabfrage verwendet die folgenden Parameter: *prozent\$1an\$1ausfällen* Der Prozentsatz des Datenträgers, der während des Ausfallereignisses als ausgefallen markiert werden soll. Dieser Wert kann ein Duplikat zwischen 0 und 100 sein. Wenn Sie 0 festlegen, wird kein Segment der Festplatte als fehlerhaft markiert. Wenn Sie 100 festlegen, wird die gesamte Festplatte als fehlerhaft markiert. *index* Ein spezifischer logischer Datenblock, in dem das Ausfallereignis simuliert werden soll. Wenn Sie den Bereich der verfügbaren logischen Blöcke oder Speichernodedaten überschreiten, erhalten Sie eine Fehlermeldung, in der Ihnen der maximal festlegbare Indexwert angezeigt wird. Informationen zur Vermeidung dieses Fehlers finden Sie unter [Anzeigen des Volume-Status für einen Aurora PostgreSQL-DB-Cluster](AuroraPostgreSQL.Managing.VolumeStatus.md). *ist\$1festplatte* Gibt an, ob der Injektionsfehler auf einen logischen Block oder einen Speicherknoten zurückzuführen ist. Die Angabe von „true“ bedeutet, dass Injektionsfehler auf einen logischen Block zurückzuführen sind. Die Angabe von „false“ bedeutet, dass Injektionsfehler auf einen Speicherknoten zurückzuführen sind. *time\$1intervall* Die Zeitspanne für die Simulation des Datenträgerausfalls. Das Intervall ist in Sekunden. Wenn der Wert beispielsweise 20 ist, wird die Simulation 20 Sekunden lang ausgeführt. ## Testen einer Festplattenüberlastung Sie können eine Datenträgerüberlastung für einen DB-Cluster von Aurora PostgreSQL mittels der Funktion zur Fehlerinjektionsabfrage `aurora_inject_disk_congestion()` simulieren. Während einer Simulation einer Festplattenüberlastung markiert der Aurora PostgreSQL-DB-Cluster zufällige Festplattensegmente als überlastet. Anfragen an diese Segmente werden für die Dauer der angegebenen minimalen und maximalen Verzögerungszeit während der Simulation verzögert. **Syntax** ``` 1. SELECT aurora_inject_disk_congestion( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval, 6. minimum, 7. maximum 8. ); ```Optionen Diese Fehlersimulationsabfrage verwendet die folgenden Parameter: *prozent\$1an\$1ausfällen* Der Prozentsatz des Datenträgers, der während des Ausfallereignisses als überlastet markiert werden soll. Dies ist ein doppelter Wert zwischen 0 und 100. Wenn Sie 0 festlegen, wird kein Segment der Festplatte als überlastet markiert. Wenn Sie 100 festlegen, wird die gesamte Festplatte als überlastet markiert. *index* Ein spezifischer logischer Datenblock oder Speicherknoten, der zum Simulieren des Ausfallereignisses verwendet werden soll. Wenn Sie den Bereich der verfügbaren logischen Datenblöcke oder Speichernodes überschreiten, erhalten Sie eine Fehlermeldung, die Ihnen den maximalen Indexwert angibt, den Sie angeben können. Informationen zur Vermeidung dieses Fehlers finden Sie unter [Anzeigen des Volume-Status für einen Aurora PostgreSQL-DB-Cluster](AuroraPostgreSQL.Managing.VolumeStatus.md). *ist\$1festplatte* Gibt an, ob der Injektionsfehler auf einen logischen Block oder einen Speicherknoten zurückzuführen ist. Die Angabe von „true“ bedeutet, dass Injektionsfehler auf einen logischen Block zurückzuführen sind. Die Angabe von „false“ bedeutet, dass Injektionsfehler auf einen Speicherknoten zurückzuführen sind. *time\$1intervall* Die Zeitspanne für die Simulation der Datenträgerüberlastung. Das Intervall ist in Sekunden. Wenn der Wert beispielsweise 20 ist, wird die Simulation 20 Sekunden lang ausgeführt. *Minimum, Maximum* Der Mindest- und Höchstwert in Millisekunden für die Überlastungsverzögerung. Gültige Werte reichen von 0,0 bis 100,0 Millisekunden. Festplattensegmente, die als überlastet gekennzeichnet sind, werden für die Dauer der Simulation um eine zufällige Zeit innerhalb des minimalen und maximalen Bereichs verzögert. Der Höchstwert muss größer als der Mindestwert sein. # Anzeigen des Volume-Status für einen Aurora PostgreSQL-DB-Cluster In Amazon Aurora besteht ein DB-Cluster-Volume aus einer Sammlung von logischen Blöcken. Jeder von ihnen stellt 10 Gigabyte des zugeteilten Arbeitsspeichers bereit. Diese Blöcke werden als *Schutzgruppen* bezeichnet. Die Daten in den einzelnen Schutzgruppen werden über sechs physische Speichereinheiten, so genannte *Speicherknoten*, repliziert. Diese Speicherknoten sind auf drei Availability Zones (AZs) in der Region verteilt, in der sich der DB-Cluster befindet. Jeder Speicherknoten wiederum besteht aus einem oder mehreren logischen Datenblöcken für das DB-Cluster-Volume. Weitere Informationen zu Schutzgruppen und Speicherknoten finden Sie unter [Einführung in die Aurora-Speicher-Engine](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) im AWS Datenbank-Blog. Weitere Informationen über Aurora-Cluster-Volumes im Allgemeinen finden Sie unter [Amazon Aurora-Speicher](Aurora.Overview.StorageReliability.md). Verwenden Sie die Funktion `aurora_show_volume_status()`, um die folgenden Serverstatusvariablen zurückzugeben: + `Disks` – Die Gesamtanzahl der logischen Datenblöcke für das DB-Cluster-Volume. + `Nodes` **—** Die Gesamtanzahl der Speicherknoten für das DB-Cluster-Volume. Sie können die Funktion `aurora_show_volume_status()` verwenden, um einen Fehler zu vermeiden, wenn Sie die Fehlersimulationsfunktion `aurora_inject_disk_failure()` verwenden. Die Fehlersimulationsfunktion `aurora_inject_disk_failure()` simuliert den Ausfall eines gesamten Speicherknotens oder eines einzelnen logischen Datenblocks innerhalb eines Speicherknotens. In der Funktion geben Sie den Indexwert eines spezifischen logischen Datenblocks oder Speicherknotens an. Die Anweisung gibt jedoch einen Fehler zurück, wenn Sie einen Indexwert angeben, der größer ist als die Anzahl der logischen Datenblöcke oder Speicherknoten, die vom DB-Cluster-Volume verwendet werden. Weitere Informationen über Fehlersimulationsabfragen finden Sie unter [Testen von Amazon Aurora PostgreSQL unter Verwendung von Fehlersimulationsabfragen](AuroraPostgreSQL.Managing.FaultInjectionQueries.md). **Anmerkung** Die Funktion `aurora_show_volume_status()` steht für Aurora PostgreSQL-Version 10.11 zur Verfügung. Weitere Informationen zu den Aurora PostgreSQL-Versionen erhalten Sie unter [Amazon Aurora PostgreSQL Releases und Engine Versionen](AuroraPostgreSQL.Updates.20180305.md). **Syntax** ``` 1. SELECT * FROM aurora_show_volume_status(); ``` **Beispiel** ``` customer_database=> SELECT * FROM aurora_show_volume_status(); disks | nodes -------+------- 96 | 45 ``` # RAM-Datenträger für das stats\$1temp\$1directory Sie können den Aurora-PostgreSQL-Parameter `rds.pg_stat_ramdisk_size` verwenden, um den Systemspeicher anzugeben, der einer RAM-Disk für die Speicherung von PostgreSQL `stats_temp_directory`. Der RAM-Disk-Parameter ist für alle Aurora-PostgreSQL-14-Versionen und niedriger verfügbar. Bei bestimmten Workloads kann durch die Einstellung dieses Parameters die Leistung verbessert und die I/O-Anforderungen können gesenkt werden. Weitere Informationen über `stats_temp_directory` finden Sie unter [Laufzeitstatistik](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY) in der PostgreSQL-Dokumentation. Ab PostgreSQL Version 15 hat die PostgreSQL-Community auf die Verwendung von dynamischem gemeinsam genutztem Speicher Memory umgestellt. Eine Einstellung von `stats_temp_directory` ist also nicht erforderlich. Um einen RAM-Datenträger für Ihr `stats_temp_directory` zu aktivieren, legen Sie den Parameter `rds.pg_stat_ramdisk_size` in der von Ihrer DB-Cluster verwendeten Parametergruppe auf einen Wert ungleich Null fest. Dieser Parameter wird in MB angegeben, daher müssen Sie einen ganzzahligen Wert verwenden. Ausdrücke, Formeln und Funktionen sind für den Parameter `rds.pg_stat_ramdisk_size` nicht gültig. Stellen Sie sicher, dass Sie den DB-Cluster neu starten, damit die Änderungen wirksam werden. Weitere Informationen zum Festlegen von Parametern finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md). Weitere Informationen zum Neustart einer Verbindung mit dem DB-Cluster finden Sie unter [Neustart eines Amazon Aurora DB-Clusters oder einer Amazon Aurora DB-Instance](USER_RebootCluster.md). Der folgende AWS CLI Befehl legt beispielsweise den RAM-Disk-Parameter auf 256 MB fest. ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name db-cl-pg-ramdisk-testing \ --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot" ``` Nachdem Sie den DB-Cluster neu gestartet haben, führen Sie den folgenden Befehl aus, um den Status des 1:`stats_temp_directory` ``` postgres=> SHOW stats_temp_directory; ``` Der Befehl sollte Folgendes zurückgeben: ``` stats_temp_directory --------------------------- /rdsdbramdisk/pg_stat_tmp (1 row) ``` # Verwalten temporärer Dateien mit PostgreSQL In PostgreSQL kann eine komplexe Abfrage möglicherweise mehrere Sortier- und Hash-Vorgänge gleichzeitig durchführen, wobei jeder Vorgang Instance-Speicher verwendet, um Ergebnisse bis zu dem im [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) angegebenen Wert zu speichern. Wenn der Instance-Speicher nicht ausreicht, werden temporäre Dateien erstellt, um die Ergebnisse zu speichern. Diese werden auf die Festplatte geschrieben, um die Abfrageausführung abzuschließen. Später werden diese Dateien automatisch entfernt, nachdem die Abfrage abgeschlossen ist. In In Aurora PostgreSQL teilen sich diese Dateien den lokalen Speicher mit anderen Protokolldateien. Sie können den lokalen Speicherplatz Ihres Aurora PostgreSQL-DB-Clusters überwachen, indem Sie die CloudWatch Amazon-Metrik für beobachten. `FreeLocalStorage` Weitere Informationen finden Sie unter [ Behebung lokaler Speicherprobleme](https://aws.amazon.com/premiumsupport/knowledge-center/postgresql-aurora-storage-issue/). Wir empfehlen die Verwendung von Clustern für Aurora-optimierte Lesevorgänge für Workloads mit mehreren gleichzeitigen Abfragen, die mehr temporäre Dateien nutzen. Diese verwenden lokalen, auf Non-Volatile Memory Express (NVMe) basierenden Solid-State-Drive-Speicher (SSD) auf Blockebene, um die temporären Dateien zu platzieren. Weitere Informationen finden Sie unter [Verbesserung der Abfrageleistung für Aurora PostgreSQL mit Aurora-optimierten Lesevorgängen](AuroraPostgreSQL.optimized.reads.md). Sie können die folgenden Parameter und Funktionen verwenden, um die temporären Dateien in Ihrer Instance zu verwalten. + **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – Dieser Parameter bricht jede Abfrage ab, die die Größe von temp\$1files in KB überschreitet. Dieses Limit verhindert, dass Abfragen endlos ausgeführt werden und Speicherplatz mit temporären Dateien belegen. Sie können den Wert anhand der Ergebnisse des Parameters `log_temp_files` schätzen. Es hat sich bewährt, das Workload-Verhalten zu untersuchen und das Limit der Schätzung entsprechend festzulegen. Das folgende Beispiel zeigt, wie eine Abfrage abgebrochen wird, wenn sie das Limit überschreitet. ``` postgres=>select * from pgbench_accounts, pg_class, big_table; ``` ``` ERROR: temporary file size exceeds temp_file_limit (64kB) ``` + **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – Dieser Parameter sendet Nachrichten an die Datei postgresql.log, wenn die temporären Dateien einer Sitzung entfernt werden. Dieser Parameter erstellt Protokolle, nachdem eine Abfrage erfolgreich abgeschlossen wurde. Daher ist er bei der Fehlerbehebung aktiver, lang andauernder Abfragen möglicherweise nicht hilfreich. Das folgende Beispiel zeigt, dass nach erfolgreichem Abschluss der Abfrage die Einträge in der Datei postgresql.log protokolliert werden, während die temporären Dateien bereinigt werden. ``` 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; ``` + **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – Diese Funktion, die von RDS für PostgreSQL 13 und höher verfügbar ist, bietet Einblick in die aktuelle Nutzung temporärer Dateien. Die abgeschlossene Abfrage erscheint nicht in den Ergebnissen der Funktion. Im folgenden Beispiel können Sie sich die Ergebnisse dieser Funktion ansehen. ``` postgres=>select * from pg_ls_tmpdir(); ``` ``` name | size | modification -----------------+------------+------------------------ pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00 pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00 pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00 pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00 pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00 (7 rows) ``` ``` postgres=>select query from pg_stat_activity where pid = 8355; query ---------------------------------------------------------------------------------------- select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid (1 row) ``` Der Dateiname enthält die Verarbeitungs-ID (PID) der Sitzung, die die temporäre Datei generiert hat. Eine komplexere Abfrage, wie im folgenden Beispiel, führt eine Summenberechnung der temporären Dateien für jede PID durch. ``` postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid; ``` ``` pid | count | sum ------+------------------- 8355 | 2 | 2144501760 8351 | 2 | 2090770432 8327 | 1 | 1072250880 8328 | 2 | 2144501760 (4 rows) ``` + **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – Wenn Sie den Parameter pg\$1stat\$1statements aktivieren, können Sie die durchschnittliche Nutzung temporärer Dateien pro Aufruf einsehen. Sie können die query\$1id der Abfrage identifizieren und verwenden, um die Nutzung temporärer Dateien zu untersuchen, wie im folgenden Beispiel gezeigt. ``` postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%'; ``` ``` queryid ---------------------- -7170349228837045701 (1 row) ``` ``` postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701; ``` ``` queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call ----------------------+---------------------------+-------+-------------------------+---------------------------- -7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678 (1 row) ``` + **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** – Im Performance-Insights-Dashboard können Sie die Nutzung temporärer Dateien einsehen, indem Sie die Metriken **temp\$1bytes** und **temp\$1files** aktivieren. Anschließend können Sie den Durchschnitt dieser beiden Metriken sehen und feststellen, wie sie dem Abfrage-Workload entsprechen. In der Ansicht in Performance Insights werden nicht speziell die Abfragen angezeigt, die die temporären Dateien generieren. Wenn Sie jedoch Performance Insights mit der für `pg_ls_tmpdir` angezeigten Abfrage kombinieren, können Sie Fehler in Ihrem Abfrage-Workload beheben, analysieren und die Änderungen ermitteln. Weitere Informationen zur Analyse von Metriken und Abfragen mit Performance Insights finden Sie unter [Analyse der Metriken mit dem Performance-Insights-Dashboard](USER_PerfInsights.UsingDashboard.md). Ein Beispiel für die Anzeige der Nutzung temporärer Dateien mit Performance Insights finden Sie unter [Anzeigen der Nutzung temporärer Dateien mit Performance Insights](PostgreSQL.ManagingTempFiles.Example.md). # Anzeigen der Nutzung temporärer Dateien mit Performance Insights Sie können Performance Insights verwenden, um die Nutzung temporärer Dateien anzuzeigen, indem Sie die Metriken **temp\$1bytes** und **temp\$1files** aktivieren. Die Ansicht in Performance Insights zeigt nicht die spezifischen Abfragen an, die temporäre Dateien generieren. Wenn Sie jedoch Performance Insights mit der für `pg_ls_tmpdir` angezeigten Abfrage kombinieren, können Sie Fehler beheben, analysieren und die Änderungen in Ihrem Abfrage-Workload ermitteln. 1. Wählen Sie im Performance-Insights-Dashboard **Metriken verwalten** aus. 1. Wählen Sie **Datenbankmetriken** und die Metriken **temp\$1bytes** und **temp\$1files** aus, wie im folgenden Screenshot gezeigt. ![\[Im Diagramm dargestellte Metriken.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_metrics.png) 1. Wählen Sie auf der Registerkarte **Top SQL** das Symbol **Einstellungen** aus. 1. Schalten Sie im Fenster **Einstellungen** die folgenden Statistiken ein, damit sie auf der Registerkarte **Top SQL** angezeigt werden, und wählen Sie **Weiter** aus. + Temporäre Schreibvorgänge pro Sekunde + Temporäre Lesevorgänge pro Sekunde + Temporäre Massenschreibvorgänge/Aufruf + Temporäre Massenlesevorgänge/Aufruf 1. Die temporäre Datei wird aufgegliedert, wenn sie mit der für `pg_ls_tmpdir` gezeigten Abfrage kombiniert wird, wie im folgenden Beispiel gezeigt. ![\[Abfrage, die die Nutzung temporärer Dateien anzeigt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_query.png) Die `IO:BufFileRead`- und `IO:BufFileWrite`-Ereignisse treten auf, wenn die häufigsten Abfragen in Ihrem Workload häufig temporäre Dateien erstellen. Mit Performance Insights können Sie die häufigsten Abfragen identifizieren, die auf `IO:BufFileRead` und `IO:BufFileWrite` warten, indem Sie die Abschnitte Durchschnittliche aktive Vorträge (AAS) in Datenbanklast und Top SQL überprüfen. ![\[IO: BufFileRead und IO: BufFileWrite in der Grafik.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/perfinsights_IOBufFile.png) Weitere Informationen zur Analyse von Top-Abfragen und Last nach Warteereignis mit Performance Insights finden Sie unter [Überblick über die Registerkarte „Top SQL“](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Sie sollten die Abfragen identifizieren und optimieren, die zu einer erhöhten Nutzung temporärer Dateien und damit verbundenen Warteereignissen führen. Weitere Informationen zu diesen Warteereignissen und deren Behebung finden Sie unter [IO: BufFileRead und IO: BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.iobuffile.html). **Anmerkung** Der Parameter [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) steuert, wann der Sortiervorgang nicht mehr genügend Speicherplatz hat und die Ergebnisse in temporäre Dateien geschrieben werden. Wir empfehlen, die Einstellung dieses Parameters nicht höher als auf den Standardwert festzulegen, da dadurch jede Datenbanksitzung mehr Speicher belegen würde. Außerdem kann eine einzelne Sitzung, die komplexe Verknüpfungen und Sortierungen durchführt, parallele Operationen ausführen, bei denen jeder Vorgang Speicherplatz belegt. Wenn Sie einen umfangreichen Bericht mit mehreren Verknüpfungen und Sortierungen haben, empfiehlt es sich, diesen Parameter mit dem Befehl `SET work_mem` auf Sitzungsebene festzulegen. Dann wird die Änderung nur auf die aktuelle Sitzung angewendet und der Wert nicht global geändert.