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.
# IO:WALWrite
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.iowalwrite.context.supported)
+ [Kontext](#wait-event.iowalwrite.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.iowalwrite.causes)
+ [Aktionen](#wait-event.iowalwrite.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL 10 und höher unterstützt.
## Kontext
Die Aktivität in der Datenbank, die Write-Ahead-Protokolldaten generiert, füllt zuerst die WAL-Puffer und schreibt dann asynchron auf die Festplatte. Das Warteereignis `IO:WALWrite` wird generiert, wenn die SQL-Sitzung darauf wartet, dass die WAL-Daten das Schreiben auf die Festplatte abgeschlossen haben, damit sie den COMMIT-Aufruf der Transaktion freigeben kann.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn dieses Warteereignis häufig auftritt, sollten Sie Ihre Workload und die Art der Aktualisierungen, die Ihre Workload durchführt, sowie deren Häufigkeit überprüfen. Suchen Sie insbesondere nach folgender Art von Aktivität.
**Starke DML-Aktivität**
Das Ändern von Daten in Datenbanktabellen erfolgt nicht sofort. Beim Einfügen in eine Tabelle muss möglicherweise auf eine Einfügung oder Aktualisierung derselben Tabelle von einem anderen Client gewartet werden. Die Data Manipulation Language (DML)-Anweisungen zum Ändern von Datenwerten (INSERT, UPDATE, DELETE, COMMIT, ROLLBACK TRANSACTION) können Konflikte verursachen, die dazu führen, dass die Write-Ahead-Protokolldatei darauf wartet, dass die Puffer geleert werden. Diese Situation wird in den folgenden Metriken für Erkenntnisse zur Amazon-RDS-Leistung erfasst, die auf eine starke DML-Aktivität hinweisen.
+ `tup_inserted`
+ `tup_updated`
+ `tup_deleted`
+ `xact_rollback`
+ `xact_commit`
Weitere Informationen zu diesen Metriken finden Sie unter [Performance-Insights-Zähler für Amazon RDS für PostgreSQL](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.PostgreSQL).
**Häufige Checkpoint-Aktivitäten**
Häufige Checkpoints tragen zu einer höheren Anzahl von WAL-Dateien bei. In RDS für PostgreSQL sind Schreibvorgänge für vollständige Seiten immer aktiviert. Schreibvorgänge für vollständige Seiten schützen vor Datenverlust. Wenn Checkpoints jedoch zu häufig auftreten, kann es zu Leistungseinbußen des Systems kommen. Dies gilt insbesondere für Systeme mit starker DML-Aktivität. In einigen Fällen finden Sie möglicherweise Fehlermeldungen in Ihrem `postgresql.log`, dass „Checkpoints zu häufig vorkommen“.
Wir empfehlen, bei der Optimierung von Checkpoints die Leistung sorgfältig gegen den erwarteten Zeitbedarf für die Wiederherstellung im Falle eines abnormalen Shutdowns abzuwägen.
## Aktionen
Wir empfehlen die folgenden Aktionen, um die Vorkommen dieses Warteereignis zu reduzieren.
**Topics**
+ [Reduzieren Sie die Anzahl der Commits](#wait-event.iowalwrite.actions.problem)
+ [Überwachen Ihrer Checkpoints](#wait-event.iowalwrite.actions.monitor)
+ [Hochskalieren von I/O](#wait-event.iowalwrite.actions.scale-io)
+ [Dediziertes Protokoll-Volume (DLV)](#wait-event.iowalwrite.actions.dlv)
### Reduzieren Sie die Anzahl der Commits
Um die Anzahl der Commits zu reduzieren, können Sie Anweisungen in Transaktionsblöcke kombinieren. Verwenden Sie Erkenntnisse zur Amazon-RDS-Leistung, um die Art der ausgeführten Abfragen zu untersuchen. Sie können große Wartungsvorgänge auch auf Zeiten außerhalb der Spitzenzeiten verlegen. Erstellen Sie beispielsweise Indizes oder verwenden Sie `pg_repack`-Operationen außerhalb der Produktionszeiten.
### Überwachen Ihrer Checkpoints
Es gibt zwei Parameter, die Sie überwachen können, um zu sehen, wie oft Ihre DB-Instance von RDS für PostgreSQL wegen Checkpoints in die WAL-Datei schreibt.
+ `log_checkpoints` – Dieser Parameter ist standardmäßig aktiviert. Dadurch wird für jeden Checkpoint eine Nachricht an das PostgreSQL-Protokoll gesendet. Diese Protokollnachrichten enthalten die Anzahl der geschriebenen Puffer, die für das Schreiben aufgewendete Zeit und die Anzahl der für den angegebenen Checkpoint hinzugefügten, entfernten oder recycelten WAL-Dateien.
Weitere Informationen zu diesem Parameter finden Sie unter [Fehlerberichte und -protokollierung](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-CHECKPOINTS) in der PostgreSQL-Dokumentation.
+ `checkpoint_warning` – Dieser Parameter legt einen Schwellenwert (in Sekunden) für die Checkpoint-Häufigkeit fest, bei dessen Überschreitung eine Warnung generiert wird. Standardmäßig ist dieser Parameter in RDS für PostgreSQL nicht festgelegt. Sie können den Wert dieses Parameters festlegen, um eine Warnung zu erhalten, wenn die Datenbankänderungen in Ihrer RDS-für-PostgreSQL-DB-Instance mit einer Geschwindigkeit geschrieben werden, für die die WAL-Dateien nicht dimensioniert sind. Angenommen, Sie haben diesen Parameter auf 30 festgelegt. Wenn Ihre RDS-für-PostgreSQL-Instance Änderungen öfter als alle 30 Sekunden schreiben muss, wird die Warnung bezüglich zu häufig vorkommender Checkpoints an das PostgreSQL-Protokoll gesendet. Dies kann darauf hindeuten, dass Ihr `max_wal_size`-Wert erhöht werden sollte.
Weitere Informationen finden Sie unter [Write-Ahead-Protokoll](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS) in der PostgreSQL-Dokumentation.
### Hochskalieren von I/O
Diese Art von Input/Output-Warteereignis (I/O) kann behoben werden, indem die Eingabe-/Ausgabevorgänge pro Sekunde (IOPs) skaliert werden, um schnellere I/O bereitzustellen. Die Skalierung von I/O ist der Skalierung der CPU vorzuziehen, da die Skalierung der CPU zu noch mehr I/O-Konflikten führen kann. Der Grund hierfür ist, dass die erhöhte CPU mehr Arbeit bewältigen kann und somit den I/O-Engpass noch verschlimmert. Im Allgemeinen empfehlen wir, die Workload zu optimieren, bevor Sie Skalierungsvorgänge durchführen.
### Dediziertes Protokoll-Volume (DLV)
Sie können ein dediziertes Protokoll-Volume (DLV) für eine DB-Instance, die Provisioned IOPS (PIOPS)-Speicher verwendet, mithilfe der Amazon-RDS-Konsole, AWS CLI oder der Amazon-RDS-API verwenden. Ein DLV verschiebt PostgreSQL-Datenbank-Transaktionsprotokolle auf ein Speicher-Volume, das von dem Volume getrennt ist, das die Datenbanktabellen enthält. Weitere Informationen finden Sie unter [Dediziertes Protokoll-Volume (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).