;
```
Wenn die Deaktivierung der Parallelität zu besseren oder konsistenteren Ergebnissen führt, sollten Sie erwägen, sie für bestimmte Abfragen auf Sitzungsebene mithilfe von SET-Befehlen zu deaktivieren. Um eine umfassendere Wirkung zu erzielen, können Sie die Parallelität auf Instance-Ebene deaktivieren, indem Sie die entsprechenden Parameter in Ihrem Cluster oder Ihrer Instance-Parametergruppe anpassen. Weitere Informationen finden Sie unter [Amazon-Aurora-PostgreSQL-Parameter](AuroraPostgreSQL.Reference.ParameterGroups.md).
### Überwachen der Verwendung paralleler Abfragen
Verwenden Sie die folgenden Abfragen, um einen Einblick in die Aktivität und Kapazität paralleler Abfragen zu gewinnen:
Überprüfen Sie die aktiven, parallelen Worker-Prozesse:
```
SELECT
COUNT(*)
FROM
pg_stat_activity
WHERE
backend_type = 'parallel worker';
```
Diese Abfrage zeigt die Anzahl der aktiven, parallelen Worker-Prozesse. Ein hoher Wert kann darauf hinweisen, dass Ihr „max\$1parallel\$1workers“ mit einem hohen Wert konfiguriert ist. Erwägen Sie, diesen zu verringern.
Überprüfen Sie gleichzeitige parallele Abfragen:
```
SELECT
COUNT(DISTINCT leader_pid)
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL;
```
Diese Abfrage gibt die Anzahl der verschiedenen Leader-Prozesse zurück, durch die parallele Abfragen gestartet wurden. Eine hohe Zahl weist hier darauf hin, dass mehrere Sitzungen gleichzeitig parallele Abfragen ausführen, was die CPU- und Speicherauslastung erhöhen kann.
### Überprüfen und Anpassen von Einstellungen für parallele Abfragen
Überprüfen Sie die folgenden Parameter, um sicherzustellen, dass sie Ihrem Workload entsprechen:
+ `max_parallel_workers`: Gesamtzahl der parallelen Worker in allen Sitzungen
+ `max_parallel_workers_per_gather`: Max. Worker-Anzahl pro Abfrage
Bei OLAP-Workloads kann eine Erhöhung dieser Werte die Leistung verbessern. Für OLTP-Workloads werden im Allgemeinen niedrigere Werte bevorzugt.
```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```
### Optimieren der Ressourcenzuweisung
Überwachen Sie die CPU-Auslastung und erwägen Sie, die Anzahl von v CPUs anzupassen, wenn sie konstant hoch ist und Ihre Anwendung von parallel Abfragen profitiert. Stellen Sie sicher, dass ausreichend Speicher für parallele Operationen verfügbar ist.
+ Ermitteln Sie anhand von Performance Insights, ob das System CPU-gebunden ist.
+ Jeder parallele Worker verwendet seinen eigenen `work_mem`. Stellen Sie sicher, dass die Gesamtspeichernutzung innerhalb der Instance-Grenzen liegt.
Parallele Abfragen können erheblich mehr Ressourcen verbrauchen als nicht parallele, da jeder Worker-Prozess ein vollständig separater Prozess ist, der ungefähr die gleichen Auswirkungen auf das System hat wie eine zusätzliche Benutzersitzung. Dies sollte bei der Auswahl eines Werts für diese Einstellung sowie bei der Konfiguration anderer Einstellungen zur Steuerung der Ressourcennutzung berücksichtigt werden, zum Beispiel `work_mem`. Weitere Informationen finden Sie in der [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Ressourcenbegrenzungen, wie `work_mem` werden individuell auf jeden Worker angewendet, das bedeutet, dass die Gesamtauslastung über alle Prozesse hinweg viel höher sein kann, als dies normalerweise für einen einzelnen Prozess der Fall wäre.
Erwägen Sie, v zu erhöhen CPUs oder die Speicherparameter zu optimieren, wenn Ihre Arbeitslast stark parallelisiert ist.
### Untersuchen der Verbindungsverwaltung
Wenn die Verbindung überlastet ist, prüfen Sie Strategien für ein Verbindungspooling der Anwendung. Erwägen Sie die Implementierung von Verbindungspooling auf Anwendungsebene, sofern es nicht bereits verwendet wird.
### Überprüfen und Optimieren von Wartungsvorgängen
Koordinieren Sie die Indexerstellung und andere Wartungsaufgaben, um Ressourcenkonflikte zu vermeiden. Erwägen Sie, diese Vorgänge für Zeiten außerhalb der Spitzenzeiten einzuplanen. Vermeiden Sie es, umfangreiche Wartungsvorgänge (z. B. parallele Indexerstellungen) für Zeiten mit hoher Benutzerabfragelast einzuplanen. Diese Operationen können parallele Worker beanspruchen und die Leistung bei regulären Abfragen negativ beeinträchtigen.
### Verwenden der Abfrageplanverwaltung (QPM)
In Amazon Aurora PostgreSQL ist das Abfrageplanverwaltung (QPM)-Feature so ausgelegt, dass die Anpassungsfähigkeit und Stabilität des Plans unabhängig von Änderungen der Datenbankumgebung, die zu einer Regression des Abfrageplans führen könnten, sichergestellt ist. Weitere Informationen finden Sie unter [Übersicht über die Abfrageplanverwaltung in Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md). QPM bietet eine gewisse Kontrolle über den Optimierer. Überprüfen Sie die genehmigten Pläne in QPM, um sicherzustellen, dass sie den aktuellen Parallelitätseinstellungen entsprechen. Aktualisieren oder entfernen Sie veraltete Pläne, die möglicherweise eine suboptimale parallele Ausführung erzwingen.
Sie können die Pläne auch mit pg\$1hint\$1plan korrigieren. Weitere Informationen finden Sie unter [Reparieren von Plänen mit pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan). Sie können mit dem `Parallel`-Hinweis eine parallele Ausführung erzwingen. Weitere Informationen finden Sie in unter [Hints for parallel plans](https://github.com/ossc-db/pg_hint_plan/blob/master/docs/hint_table.md#hints-for-parallel-plans).
# IPC: ProcArrayGroupUpdate
Das `IPC:ProcArrayGroupUpdate` Ereignis tritt ein, wenn eine Sitzung darauf wartet, dass der Gruppenleiter den Transaktionsstatus am Ende des Vorgangs aktualisiert. Während PostgreSQL im Allgemeinen Warteereignisse vom Typ IPC mit parallel Abfrageoperationen verknüpft, ist dieses spezielle Wartungsereignis nicht spezifisch für parallel Abfragen.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-rpg-ipcprocarraygroup.supported)
+ [Kontext](#apg-rpg-ipcprocarraygroup.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-rpg-ipcprocarraygroup.causes)
+ [Aktionen](#apg-rpg-ipcprocarraygroup.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
## Kontext
**Das Prozessarray verstehen** — Das Prozessarray (proc) ist eine gemeinsam genutzte Speicherstruktur in PostgreSQL. Es enthält Informationen über alle laufenden Prozesse, einschließlich Transaktionsdetails. Während des Abschlusses der Transaktion (`COMMIT`oder`ROLLBACK`) ProcArray muss die Datei aktualisiert werden, um die Änderung widerzuspiegeln und die TransactionID aus dem Array zu löschen. Die Sitzung, die versucht, ihre Transaktion abzuschließen, muss eine exklusive Sperre für erhalten. ProcArray Dadurch wird verhindert, dass andere Prozesse gemeinsame oder exklusive Sperren für die Datei erhalten.
**Mechanismus zur Gruppenaktualisierung** — Wenn ein Back-End-Prozess bei der Ausführung eines COMMIT- oder ROLLBACK-Vorgangs ProcArrayLock im exklusiven Modus keinen Wert abrufen kann, aktualisiert er ein spezielles Feld mit dem Namen. ProcArrayGroupMember Dadurch wird die Transaktion der Liste der Sitzungen hinzugefügt, die beendet werden sollen. Dieser Backend-Prozess schläft dann, und die Zeit, in der er sich befindet, wird als ProcArrayGroupUpdate Warteereignis instrumentiert. Der erste Prozess im ProcArray procArrayGroup With-Member, der als Leader-Prozess bezeichnet wird, erfolgt ProcArrayLock im exklusiven Modus. Anschließend wird die Liste der Prozesse gelöscht, die auf das Löschen der GruppentransactionID warten. Sobald dieser Vorgang abgeschlossen ist, gibt der Leader alle Prozesse in dieser Liste frei ProcArrayLock und aktiviert sie, sodass sie darüber informiert werden, dass ihre Transaktion abgeschlossen ist.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Je mehr Prozesse ausgeführt werden, desto länger hält ein Leader an einem procArrayLock im exklusiven Modus fest. Je mehr Schreibtransaktionen in einem Gruppenaktualisierungsszenario enden, was zu einer potenziellen Anhäufung von Prozessen führt, die auf das Warteereignis `ProcArrayGroupUpdate` warten. In der Top-SQL-Ansicht von Database Insights werden Sie sehen, dass COMMIT die Anweisung ist, bei der der Großteil dieses Warteereignisses auftritt. Dies ist zu erwarten, erfordert jedoch eine eingehendere Untersuchung der spezifischen Schreib-SQL, die gerade ausgeführt wird, um festzustellen, welche geeigneten Maßnahmen zu ergreifen sind.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. Identifizieren Sie `IPC:ProcArrayGroupUpdate` Ereignisse mithilfe von Amazon RDS Performance Insights oder durch Abfragen der PostgreSQL-Systemansicht. `pg_stat_activity`
**Topics**
+ [Überwachung von Transaktions-, Commit- und Rollback-Vorgängen](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [Reduzierung der Parallelität](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [Implementierung von Verbindungspooling](#apg-rpg-ipcprocarraygroup.actions.pooling)
### Überwachung von Transaktions-, Commit- und Rollback-Vorgängen
**Überwachen Sie Commits und Rollbacks** — Eine erhöhte Anzahl von Commits und Rollbacks kann zu einem erhöhten Druck auf die führen. ProcArray Wenn beispielsweise eine SQL-Anweisung aufgrund einer erhöhten Anzahl von Verletzungen doppelter Schlüssel zu scheitern beginnt, kann es zu einer Zunahme von Rollbacks kommen, was wiederum zu Konflikten und zu einer Überlastung der Tabellen führen kann. ProcArray
Amazon RDS Database Insights stellt die PostgreSQL-Metriken `xact_rollback` bereit `xact_commit` und berichtet über die Anzahl der Commits und Rollbacks pro Sekunde.
### Reduzierung der Parallelität
**Batch-Transaktionen** — Wenn möglich, sollten Operationen in Einzeltransaktionen gebündelt werden, um die Anzahl der Operationen zu reduzieren commit/rollback .
**Parallelität einschränken** — Reduzieren Sie die Anzahl der gleichzeitig aktiven Transaktionen, um Sperrkonflikte bei der zu vermeiden. ProcArray Es sind zwar einige Tests erforderlich, aber eine Reduzierung der Gesamtzahl gleichzeitiger Verbindungen kann Konflikte reduzieren und den Durchsatz aufrechterhalten.
### Implementierung von Verbindungspooling
**Verbindungspooling-Lösungen** — Verwenden Sie Verbindungspooling, um Datenbankverbindungen effizient zu verwalten und so die Gesamtzahl der Backends und damit die Arbeitslast auf dem zu reduzieren. ProcArray Es sind zwar einige Tests erforderlich, aber die Reduzierung der Gesamtzahl gleichzeitiger Verbindungen kann Konflikte reduzieren und den Durchsatz aufrechterhalten.
Weitere Informationen finden Sie unter [Verbindungspooling für Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.connection_pooling.html).
**Reduzieren Sie Verbindungsstürme** — In ähnlicher Weise führt ein Muster, bei dem häufig Verbindungen hergestellt und beendet werden, zu zusätzlichem Druck auf die. ProcArray Durch die Reduzierung dieses Musters werden Konflikte insgesamt reduziert.
# Lock:advisory
Das `Lock:advisory`-Ereignis tritt auf, wenn eine PostgreSQL-Anwendung eine Sperre verwendet, um Aktivitäten über mehrere Sitzungen hinweg zu koordinieren.
**Topics**
+ [Relevante Engine-Versionen](#apg-waits.lockadvisory.context.supported)
+ [Kontext](#apg-waits.lockadvisory.context)
+ [Ursachen](#apg-waits.lockadvisory.causes)
+ [Aktionen](#apg-waits.lockadvisory.actions)
## Relevante Engine-Versionen
Diese Warteereignisinformationen sind für Aurora PostgreSQL Versionen 9.6 und höher relevant.
## Kontext
PostgreSQL-Beratungssperren sind Anwendungsebene, kooperative Sperren werden explizit durch den Anwendungscode des Benutzers gesperrt und freigeschaltet. Eine Anwendung kann PostgreSQL-Beratungssperren verwenden, um Aktivitäten über mehrere Sitzungen hinweg zu koordinieren. Im Gegensatz zu normalen Sperren auf Objekt- oder Zeilenebene hat die Anwendung die volle Kontrolle über die Lebensdauer des Schlosses. Weitere Informationen finden Sie unter [Empfohlene Sperren](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) in der PostgreSQL-Dokumentation.
Beratungssperren können vor dem Ende einer Transaktion freigegeben werden oder von einer Sitzung über Transaktionen hinweg gehalten werden. Dies gilt nicht für implizite, vom System erzwungene Sperren, wie z. B. eine zugriffsexklusive Sperre für eine Tabelle, die von einer `CREATE INDEX`-Anweisung abgerufen wird.
Eine Beschreibung der Funktionen zum Erlangen (Sperren) und Freigeben (Entsperren) von Advisory Locks finden Sie unter [Advisory Lock Functions](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS) in der PostgreSQL-Dokumentation.
Advisory Locks werden zusätzlich zum regulären PostgreSQL-Locking-System implementiert und sind in der `pg_locks`-Systemansicht sichtbar.
## Ursachen
Dieser Schlosstyp wird ausschließlich von einer Anwendung gesteuert, die ihn explizit verwendet. Beratungssperren, die für jede Zeile als Teil einer Abfrage erworben werden, können zu einem Anstieg der Sperren oder zu einem langfristigen Aufbau führen.
Diese Effekte treten auf, wenn die Abfrage so ausgeführt wird, dass Sperren für mehr Zeilen erwirbt, als von der Abfrage zurückgegeben werden. Die Anwendung muss schließlich jede Sperre freigeben, aber wenn Sperren für Zeilen erworben werden, die nicht zurückgegeben werden, kann die Anwendung nicht alle Sperren finden.
Das folgende Beispiel stammt aus [Empfohlene Sperren](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) in der PostgreSQL-Dokumentation.
```
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100;
```
In diesem Beispiel kann die `LIMIT`-Klausel die Ausgabe der Abfrage nur stoppen, nachdem die Zeilen bereits intern ausgewählt und ihre ID-Werte gesperrt wurden. Dies kann plötzlich passieren, wenn ein wachsendes Datenvolumen dazu führt, dass der Planer einen anderen Ausführungsplan auswählt, der während der Entwicklung nicht getestet wurde. Der Aufbau erfolgt in diesem Fall, weil die Anwendung `pg_advisory_unlock` explizit für jeden gesperrten ID-Wert aufruft. In diesem Fall kann es jedoch nicht die Sperren finden, die für Zeilen erworben wurden, die nicht zurückgegeben wurden. Da die Sperren auf Sitzungsebene erworben werden, werden sie am Ende der Transaktion nicht automatisch freigegeben.
Eine weitere mögliche Ursache für Spikes bei blockierten Sperrversuchen sind unbeabsichtigte Konflikte. In diesen Konflikten teilen sich nicht verwandte Teile der Anwendung versehentlich denselben Sperren-ID-Raum.
## Aktionen
Überprüfen Sie die Anwendungsnutzung von Beratungssperren und Details, wo und wann im Anwendungsablauf jede Art von Beratungssperre erworben und freigegeben wird.
Stellen Sie fest, ob eine Sitzung zu viele Sperren erwirbt oder eine lang andauernde Sitzung keine Sperren früh genug freigibt, was zu einem langsamen Aufbau von Sperren führt. Sie können einen langsamen Aufbau von Sperren auf Sitzungsebene korrigieren, indem Sie die Sitzung mit `pg_terminate_backend(pid)` beenden.
Ein Client, der auf eine Beratungssperre wartet, erscheint in `pg_stat_activity` mit `wait_event_type=Lock` und `wait_event=advisory`. Sie können bestimmte Sperrwerte erhalten, indem Sie die `pg_locks`-Systemansicht nach demselben `pid` abfragen und nach `locktype=advisory` und `granted=f` suchen.
Sie können dann die blockierende Sitzung identifizieren, indem Sie `pg_locks` nach derselben beratenden Sperre mit `granted=t` abfragen, wie im folgenden Beispiel gezeigt.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
Alle API-Funktionen für beratende Sperren haben zwei Sätze von Argumenten, entweder ein `bigint`-Argument oder zwei `integer`-Argumente:
+ Bei den API-Funktionen mit einem `bigint`-Argument befinden sich die oberen 32 Bit in `pg_locks.classid` und die unteren 32 Bit in `pg_locks.objid`.
+ Bei den API-Funktionen mit zwei `integer`-Argumenten ist das erste Argument `pg_locks.classid` und das zweite Argument ist `pg_locks.objid`.
Der `pg_locks.objsubid`-Wert gibt an, welches API-Formular verwendet wurde: `1` bedeutet ein `bigint`-Argument; `2` bedeutet zwei `integer`-Argumente.
# Lock:extend
Das `Lock:extend`-Ereignis tritt ein, wenn ein Backend-Prozess darauf wartet, eine Beziehung zu sperren, um sie zu erweitern, während ein anderer Prozess diese Beziehung für denselben Zweck gesperrt hat.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-waits.lockextend.context.supported)
+ [Kontext](#apg-waits.lockextend.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-waits.lockextend.causes)
+ [Aktionen](#apg-waits.lockextend.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
## Kontext
Das Ereignis `Lock:extend` zeigt an, dass ein Backend-Prozess darauf wartet, eine Beziehung zu erweitern, für die ein anderer Backend-Prozess eine Sperre hält, während er diese Beziehung erweitert. Da jeweils nur ein Prozess eine Beziehung erweitern kann, generiert das System ein `Lock:extend`-Warteereignis. `INSERT`-, `COPY`- und `UPDATE`-Vorgänge können dieses Ereignis erzeugen.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `Lock:extend`-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
**Anstieg der gleichzeitigen Einfügungen oder Aktualisierungen derselben Tabelle **
Es kann zu einer Zunahme der Anzahl gleichzeitiger Sitzungen mit Abfragen kommen, die in dieselbe Tabelle einfügen oder aktualisieren.
**Unzureichende Netzwerkbandbreite**
Die Netzwerkbandbreite auf der DB-Instance reicht möglicherweise nicht aus, um die Speicherkommunikationsanforderungen der aktuellen Workload zu gewährleisten. Dies kann zu einer Speicherlatenz führen, die zu einem Anstieg der `Lock:extend`-Ereignisse führt.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Reduzieren Sie gleichzeitige Einfügungen und Aktualisierungen auf dieselbe Beziehung](#apg-waits.lockextend.actions.action1)
+ [Erhöhung der Netzwerkbandbreite](#apg-waits.lockextend.actions.increase-network-bandwidth)
### Reduzieren Sie gleichzeitige Einfügungen und Aktualisierungen auf dieselbe Beziehung
Stellen Sie zunächst fest, ob die `tup_inserted`- und `tup_updated`-Metriken und damit auch dieses Warteereignis gestiegen ist. Überprüfen Sie in diesem Fall, welche Beziehungen für Einfüge- und Aktualisierungsvorgänge in hohem Streit stehen. Um dies zu ermitteln, fragen Sie die `pg_stat_all_tables`-Ansicht nach den Werten in den `n_tup_ins`- und `n_tup_upd`-Feldern ab. Informationen zur Ansicht `pg_stat_all_tables` finden Sie unter [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) in der PostgreSQL-Dokumentation.
Um weitere Informationen über das Blockieren und blockierte Abfragen zu erhalten, fragen Sie `pg_stat_activity` wie im folgenden Beispiel ab:
```
SELECT
blocked.pid,
blocked.usename,
blocked.query,
blocking.pid AS blocking_id,
blocking.query AS blocking_query,
blocking.wait_event AS blocking_wait_event,
blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type
------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
```
Nachdem Sie Beziehungen identifiziert haben, die zur Erhöhung von `Lock:extend`-Ereignissen beitragen, verwenden Sie die folgenden Techniken, um die Konflikte zu reduzieren:
+ Finden Sie heraus, ob Sie Partitionierung verwenden können, um die Konflikte für dieselbe Tabelle zu reduzieren. Das Trennen eingefügter oder aktualisierter Tupel in verschiedene Partitionen kann die Konflikte verringern. Weitere Informationen zur Partitionierung finden Sie unter [Verwalten von PostgreSQL-Partitionen mit der Erweiterung pg\$1partman](PostgreSQL_Partitions.md).
+ Wenn das Warteereignis hauptsächlich auf Aktualisierungsaktivitäten zurückzuführen ist, sollten Sie erwägen, den Füllfaktor-Wert der Beziehung zu reduzieren. Dies kann Anfragen nach neuen Blöcken während des Updates reduzieren. Der Füllfaktor ist ein Speicherparameter für eine Tabelle, der den maximalen Speicherplatz zum Packen einer Tabellenseite bestimmt. Es wird als Prozentsatz des gesamten Speicherplatzes für eine Seite ausgedrückt. Weitere Informationen zum Parameter fillfactor finden Sie unter [CREATE TABLE](https://www.postgresql.org/docs/13/sql-createtable.html) in der PostgreSQL-Dokumentation.
**Wichtig**
Wir empfehlen dringend, Ihr System zu testen, wenn Sie den Füllfaktor ändern, da sich die Änderung dieses Wertes je nach Workload negativ auf die Leistung auswirken kann.
### Erhöhung der Netzwerkbandbreite
Um zu sehen, ob die Schreiblatenz zunimmt, überprüfen Sie die `WriteLatency`-Metrik in CloudWatch. Wenn ja, verwenden Sie die Amazon CloudWatch-Metriken von `WriteThroughput` und `ReadThroughput`, um den speicherbezogenen Datenverkehr auf dem DB-Cluster zu überwachen. Diese Metriken können Ihnen helfen festzustellen, ob die Netzwerkbandbreite für die Speicheraktivität Ihrer Workload ausreicht.
Wenn Ihre Netzwerkbandbreite nicht ausreicht, erhöhen Sie sie. Wenn Ihre DB-Instance die Grenzen der Netzwerkbandbreite erreicht, besteht die einzige Möglichkeit, die Bandbreite zu erhöhen, darin, die Größe Ihrer DB-Instance zu erhöhen.
Weitere Informationen zu CloudWatch-Metriken finden Sie unter [CloudWatch Amazon-Metriken für Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). Informationen zur Netzwerkleistung für jede DB-Instance-Klasse finden Sie unter [Hardwarespezifikationen für DB-Instance-Klassen für Aurora](Concepts.DBInstanceClass.Summary.md).
# Lock:Relation
Das `Lock:Relation`-Ereignis tritt ein, wenn eine Abfrage darauf wartet, eine Sperre für eine Tabelle oder Sicht (Relation) zu erhalten, die derzeit von einer anderen Transaktion gesperrt ist.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-waits.lockrelation.context.supported)
+ [Kontext](#apg-waits.lockrelation.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-waits.lockrelation.causes)
+ [Aktionen](#apg-waits.lockrelation.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
## Kontext
Die meisten PostgreSQL-Befehle verwenden implizit Sperren, um den gleichzeitigen Zugriff auf Daten in Tabellen zu steuern. Sie können diese Sperren auch explizit mit dem `LOCK`-Befehl in Ihrem Anwendungscode verwenden. Viele Sperrmodi sind nicht miteinander kompatibel und können Transaktionen blockieren, wenn sie versuchen, auf dasselbe Objekt zuzugreifen. In diesem Fall generiert Aurora PostgreSQL ein `Lock:Relation`-Ereignis. Einige gängige Beispiele sind die folgenden:
+ Exklusive Sperren wie `ACCESS EXCLUSIVE` können alle gleichzeitigen Zugriffe blockieren. Vorgänge in der Datendefinitionssprache (DDL) wie `DROP TABLE`, `TRUNCATE`, `VACUUM FULL` und `CLUSTER` erwerben implizit `ACCESS EXCLUSIVE`-Sperren. `ACCESS EXCLUSIVE` ist auch der Standardsperrmodus für `LOCK TABLE`-Anweisungen, die keinen Modus explizit angeben.
+ Die Verwendung von `CREATE INDEX (without CONCURRENT)` für eine Tabelle steht in Konflikt mit den DML-Anweisungen `UPDATE`, `DELETE` und `INSERT`, die `ROW EXCLUSIVE`-Sperren anfordern.
Weitere Informationen zu Sperren auf Tabellenebene und widersprüchlichen Sperrmodi finden Sie unter [Explizite Sperren](https://www.postgresql.org/docs/13/explicit-locking.html) in der PostgreSQL-Dokumentation.
Blockieren von Abfragen und Transaktionen entsperren in der Regel auf eine der folgenden Arten:
+ Blockierende Abfrage — Die Anwendung kann die Abfrage abbrechen oder der Benutzer kann den Prozess beenden. Die Engine kann die Abfrage auch aufgrund des Statement-Timeouts einer Sitzung oder eines Deadlock-Erkennungsmechanismus zum Ende zwingen.
+ Blockieren einer Transaktion – Eine Transaktion stoppt die Blockierung, wenn sie eine `ROLLBACK`- oder `COMMIT`-Anweisung ausführt. Rollbacks erfolgen auch automatisch, wenn Sitzungen von einem Client oder durch Netzwerkprobleme getrennt oder beendet werden. Sitzungen können beendet werden, wenn das Datenbank-Engine heruntergefahren wird, wenn das System keinen Arbeitsspeicher mehr hat usw.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `Lock:Relation`-Ereignis häufiger als normal auftritt, kann dies auf ein Leistungsproblem hinweisen. Zu den typischen Ursachen zählen auch die Folgenden:
**Gleichzeitige Sitzungen mit widersprüchlichen Tabellensperren erhöht**
Es kann zu einer Zunahme der Anzahl gleichzeitiger Sitzungen mit Abfragen kommen, die dieselbe Tabelle mit widersprüchlichen Sperrmodi sperren.
**Wartungsvorgänge**
Zustandswartungsvorgänge wie `VACUUM` und `ANALYZE` können die Anzahl widersprüchlicher Sperren erheblich erhöhen. `VACUUM FULL` erhält eine `ACCESS EXCLUSIVE`-Sperre und `ANALYZE` erhält eine `SHARE UPDATE EXCLUSIVE`-Sperre. Beide Arten von Sperren können ein `Lock:Relation`-Wait-Ereignis verursachen. Wartungsvorgänge für Anwendungsdaten wie das Aktualisieren einer materialisierten Ansicht können auch blockierte Abfragen und Transaktionen erhöhen.
**Sperrt bei Reader-In**
Es könnte ein Konflikt zwischen den Beziehungssperren bestehen, die vom Writer und den Readern gehalten werden. Derzeit werden nur `ACCESS EXCLUSIVE`-Beziehungssperren auf Reader-Instances repliziert. Allerdings gerät die `ACCESS EXCLUSIVE`-Beziehungssperre in Konflikt mit jeder `ACCESS SHARE`-Beziehungssperre, die vom Reader gehalten wird. Dies kann zu einer Erhöhung der Warteereignisse für die Sperrbeziehung des Readers führen.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Reduzieren Sie die Auswirkungen der Blockierung von SQL-Anweisungen](#apg-waits.lockrelation.actions.reduce-blocks)
+ [Minimieren Sie die Auswirkungen von Wartungsvorgängen](#apg-waits.lockrelation.actions.maintenance)
+ [Auf Lesersperren überprüfen](#apg-waits.lockrelation.actions.readerlocks)
### Reduzieren Sie die Auswirkungen der Blockierung von SQL-Anweisungen
Um die Auswirkungen des Blockierens von SQL-Anweisungen zu reduzieren, ändern Sie Ihren Anwendungscode nach Möglichkeit. Es folgen zwei gängige Techniken zum Reduzieren von Blöcken:
+ Verwenden Sie die Option `NOWAIT` – Einige SQL-Befehle, wie z. B. `SELECT`- und `LOCK`-Anweisungen, unterstützen diese Option. Die `NOWAIT`-Direktive bricht die Sperre anfordernde Abfrage ab, wenn die Sperre nicht sofort erworben werden kann. Diese Technik kann dazu beitragen, zu verhindern, dass eine Blockiersitzung eine Anhäufung blockierter Sitzungen dahinter verursacht.
Beispiel: Angenommen, Transaktion A wartet auf eine Sperre, die von Transaktion B gehalten wird. Wenn B nun eine Sperre für eine Tabelle anfordert, die durch Transaktion C gesperrt ist, könnte Transaktion A blockiert werden, bis die Transaktion C abgeschlossen ist. Wenn Transaktion B jedoch ein `NOWAIT` verwendet, wenn sie die Sperre für C anfordert, kann sie schnell fehlschlagen und sicherstellen, dass Transaktion A nicht unbegrenzt warten muss.
+ Verwenden Sie `SET lock_timeout` – Legen Sie einen `lock_timeout`-Wert fest, um die Zeit zu begrenzen, die eine SQL-Anweisung wartet, um eine Sperre für eine Beziehung zu erhalten. Wenn die Sperre nicht innerhalb des angegebenen Timeouts erworben wird, wird die Transaktion, die die Sperre anfordert, abgebrochen. Stellen Sie diesen Wert auf Sitzungsebene ein.
### Minimieren Sie die Auswirkungen von Wartungsvorgängen
Wartungsvorgänge wie `VACUUM` und `ANALYZE` sind wichtig. Wir empfehlen, sie nicht zu deaktivieren, da Sie `Lock:Relation`-Warteereignisse im Zusammenhang mit diesen Wartungsvorgängen finden. Die folgenden Ansätze können die Auswirkungen dieser Vorgänge minimieren:
+ Führen Sie Wartungsvorgänge während außerhalb der Hauptverkehrszeiten manuell aus.
+ Um `Lock:Relation`-Wartezeiten zu reduzieren, die durch Autovacuum-Aufgaben verursacht werden, führen Sie alle erforderlichen Autovacuum-Optimierungen durch. Informationen zum Optimieren von Autovacuum finden Sie unter [Arbeiten mit PostgreSQL Autovacuum auf Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) im *Amazon-RDS-Benutzerhandbuch*.
### Auf Lesersperren überprüfen
Sie können sehen, wie gleichzeitige Sitzungen bei einem Autor und Lesern Sperren halten, die sich gegenseitig blockieren. Eine Möglichkeit dazu besteht darin, Abfragen auszuführen, die den Sperrtyp und die Beziehung zurückgeben. Die Tabelle enthält eine Abfolge von Abfragen für zwei dieser gleichzeitigen Sitzungen, eine Writer-Sitzung und eine Reader-Sitzung.
Der Wiedergabeprozess wartet die Dauer von `max_standby_streaming_delay` ab, bevor die Reader-Abfrage abgebrochen wird. Wie im Beispiel gezeigt, liegt das Sperr-Timeout von 100 ms deutlich unter dem standardmäßigen `max_standby_streaming_delay`-Wert von 30 Sekunden. Für die Sperre tritt ein Timeout auf, bevor ein Problem entsteht.
| Sequenzereignis | Sitzung | Befehl oder Ausgabe |
| --- | --- | --- |
| Dieses legt eine Umgebungsvariable namens READER mit dem angegebenen Wert fest und versucht, mit diesem Endpunkt eine Verbindung zur DB-Instance herzustellen. | Lesersitzung | CLI-Befehl: export READER=aurorapg2.12345678910.us-west-1.rds.amazonaws.com
psql -h $READER
Ausgabe:
```
psql (15devel, server 10.14)
Type "help" for help.
``` |
| Dieses legt eine Umgebungsvariable namens WRITER fest und versucht, mit diesem Endpunkt eine Verbindung zur DB-Instance herzustellen. | Writer session | CLI-Befehl: export WRITER=aurorapg1.12345678910.us-west-1.rds.amazonaws.com
psql -h $WRITER
Ausgabe:
```
psql (15devel, server 10.14)
Type "help" for help.
``` |
| Die Schreibsitzung erstellt die Tabelle t1 auf der Writer-Instance. | Writer session | PostgreSQL-Abfrage: postgres=> CREATE TABLE t1(b integer);
CREATE TABLE
|
| Wenn es keine widersprüchlichen Abfragen für den Writer gibt, wird sofort die ACCESS EXCLUSIVE-Sperre für den Writer erworben. | Writer session | `ACCESS EXCLUSIVE`-Sperre aktiviert |
| Die Lesesitzung legt ein Sperr-Timeout-Intervall von 100 Millisekunden fest. | Lesersitzung | PostgreSQL-Abfrage: postgres=> SET lock_timeout=100;
SET
|
| Die Lesesitzung versucht, Daten aus der Tabelle t1 auf der Reader-Instance zu lesen. | Lesersitzung | PostgreSQL-Abfrage: postgres=> SELECT * FROM t1;
Beispielausgabe:
```
b
---
(0 rows)
``` |
| Die Schreibsitzung verwirft t1. | Writer session | PostgreSQL-Abfrage: postgres=> BEGIN;
BEGIN
postgres=> DROP TABLE t1;
DROP TABLE
postgres=>
|
| Die Abfrage ist abgelaufen und wird im Reader abgebrochen. | Lesersitzung | PostgreSQL-Abfrage: postgres=> SELECT * FROM t1;
Beispielausgabe:
```
ERROR: canceling statement due to lock timeout
LINE 1: SELECT * FROM t1;
^
``` |
| Die Lesesitzung fragt `pg_locks` und `pg_stat_activity` ab, um die Fehlerursache zu ermitteln. | Lesersitzung | PostgreSQL-Abfrage: postgres=> SELECT locktype, relation, mode, backend_type
postgres=> FROM pg_locks l, pg_stat_activity t1
postgres=> WHERE l.pid=t1.pid AND relation = 't1'::regclass::oid;
|
| Das Ergebnis zeigt an, dass der `aurora wal replay`-Prozess eine `ACCESS EXCLUSIVE`-Sperre für Tabelle t1 hält. | Lesersitzung | Abfrageergebnis: locktype | relation | mode | backend_type
----------+----------+---------------------+-------------------
relation | 68628525 | AccessExclusiveLock | aurora wal replay
(1 row)
|
# Lock:transactionid
Das `Lock:transactionid`-Ereignis tritt ein, wenn eine Transaktion auf eine Sperre auf Zeilenebene wartet.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-waits.locktransactionid.context.supported)
+ [Kontext](#apg-waits.locktransactionid.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-waits.locktransactionid.causes)
+ [Aktionen](#apg-waits.locktransactionid.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
## Kontext
Das Ereignis `Lock:transactionid` tritt ein, wenn eine Transaktion versucht, eine Sperre auf Zeilenebene zu erlangen, die bereits einer gleichzeitig laufenden Transaktion gewährt wurde. Die Sitzung, die das `Lock:transactionid`-Wait-Ereignis anzeigt, ist aufgrund dieser Sperre blockiert. Nachdem die blockierende Transaktion entweder in einer `COMMIT`- oder `ROLLBACK`-Anweisung endet, kann die blockierte Transaktion fortgesetzt werden.
Die Semantik der Multiversions-Parallelität von Aurora PostgreSQL garantiert, dass Leser keine Autoren blockieren und Autoren Leser nicht blockieren. Damit Konflikte auf Zeilenebene auftreten können, müssen blockierende und blockierte Transaktionen widersprüchliche Anweisungen der folgenden Typen ausgeben:
+ `UPDATE`
+ `SELECT … FOR UPDATE`
+ `SELECT … FOR KEY SHARE`
Die Anweisung `SELECT … FOR KEY SHARE` ist ein Sonderfall. Die Datenbank verwendet die Klausel `FOR KEY SHARE`, um die Leistung der referenziellen Integrität zu optimieren. Eine Sperre auf Zeilenebene für eine Zeile kann `INSERT`-, `UPDATE`- und `DELETE`-Befehle für andere Tabellen blockieren, die auf die Zeile verweisen.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn dieses Ereignis mehr als normal auftritt, sind die Ursache normalerweise `UPDATE`-, `SELECT … FOR UPDATE`-, `SELECT … FOR KEY SHARE`-Anweisungen in Kombination mit den folgenden Bedingungen.
**Topics**
+ [Hohe Gleichzeitigkeit](#apg-waits.locktransactionid.concurrency)
+ [Leerlauf in Transaktion](#apg-waits.locktransactionid.idle)
+ [Lang laufende Transaktionen](#apg-waits.locktransactionid.long-running)
### Hohe Gleichzeitigkeit
Aurora PostgreSQL kann eine körnige Sperrsemantik auf Zeilenebene verwenden. Die Wahrscheinlichkeit von Konflikten auf Zeilenebene steigt, wenn die folgenden Bedingungen erfüllt sind:
+ Eine sehr gleichzeitige Workload beansprucht dieselben Zeilen.
+ Parallelbetrieb steigt.
### Leerlauf in Transaktion
Manchmal zeigt die Spalte `pg_stat_activity.state` den Wert `idle in transaction` an. Dieser Wert wird für Sitzungen angezeigt, die eine Transaktion gestartet, aber noch kein `COMMIT` oder `ROLLBACK` ausgegeben haben. Wenn der `pg_stat_activity.state`-Wert nicht `active` ist, ist die in `pg_stat_activity` angezeigte Abfrage die letzte, die ausgeführt wurde. Die blockierende Sitzung verarbeitet eine Abfrage nicht aktiv, da eine offene Transaktion eine Sperre hält.
Wenn eine Leerlauf-Transaktion eine Sperre auf Zeilenebene erworben hat, kann dies verhindern, dass andere Sitzungen sie erwerben. Diese Bedingung führt zu einem häufigen Auftreten des Warteereignisses `Lock:transactionid`. Um das Problem zu diagnostizieren, überprüfen Sie die Ausgabe von `pg_stat_activity` und `pg_locks`.
### Lang laufende Transaktionen
Transaktionen, die lange laufen, erhalten lange Zeit Sperren. Diese langjährigen Sperren können die Ausführung anderer Transaktionen verhindern.
## Aktionen
Zeilensperre ist ein Konflikt zwischen `UPDATE`-, `SELECT … FOR UPDATE`- oder `SELECT … FOR KEY SHARE`-Anweisungen. Bevor Sie eine Lösung versuchen, sollten Sie herausfinden, wann diese Anweisungen in derselben Zeile ausgeführt werden. Wählen Sie mit diesen Informationen eine in den folgenden Abschnitten beschriebene Strategie aus.
**Topics**
+ [Reagieren auf hohe Parallelbetrieb](#apg-waits.locktransactionid.actions.problem)
+ [Reagieren Sie auf ungenutzte Transaktionen](#apg-waits.locktransactionid.actions.find-blocker)
+ [Reagieren Sie auf lang andauernde Transaktionen](#apg-waits.locktransactionid.actions.concurrency)
### Reagieren auf hohe Parallelbetrieb
Wenn Parallelität das Problem darstellt, versuchen Sie eine der folgenden Techniken:
+ Senken Sie die Parallelität in der Anwendung. Verringern Sie beispielsweise die Anzahl der aktiven Sitzungen.
+ Implementieren Sie einen Verbindungspool. Informationen zum Poolen von Verbindungen mit RDS-Proxy finden Sie unter [Amazon RDS-Proxy für Aurora](rds-proxy.md).
+ Entwerfen Sie die Anwendung oder das Datenmodell, um konkurrierende `UPDATE`- und `SELECT … FOR UPDATE`-Anweisungen zu vermeiden. Sie können auch die Anzahl der Fremdschlüssel verringern, auf die von `SELECT … FOR KEY SHARE`-Anweisungen zugegriffen wird.
### Reagieren Sie auf ungenutzte Transaktionen
Wenn `pg_stat_activity.state` `idle in transaction` anzeigt, verwenden Sie die folgenden Strategien:
+ Schalten Sie nach Möglichkeit Autocommit ein. Dieser Ansatz verhindert, dass Transaktionen andere Transaktionen blockieren, während sie auf ein `COMMIT` oder `ROLLBACK` warten.
+ Suchen Sie nach Codepfaden, denen `COMMIT`, `ROLLBACK` oder `END` fehlt.
+ Stellen Sie sicher, dass die Ausnahmebehandlungslogik in Ihrer Anwendung immer einen Pfad zu einem gültigen `end of transaction` hat.
+ Stellen Sie sicher, dass Ihre Anwendung Abfrageergebnisse verarbeitet, nachdem die Transaktion mit `COMMIT` oder `ROLLBACK` beendet wurde.
### Reagieren Sie auf lang andauernde Transaktionen
Wenn Transaktionen mit langer Laufzeit das häufige Auftreten von `Lock:transactionid` verursachen, versuchen Sie die folgenden Strategien:
+ Halten Sie Zeilensperren von lang andauernden Transaktionen fern.
+ Beschränken Sie die Länge von Abfragen, indem Sie nach Möglichkeit Autocommit implementieren.
# Lock:tuple
Das `Lock:tuple`-Ereignis tritt ein, wenn ein Backend-Prozess darauf wartet, eine Sperre für ein Tupel zu erlangen.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-waits.locktuple.context.supported)
+ [Kontext](#apg-waits.locktuple.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-waits.locktuple.causes)
+ [Aktionen](#apg-waits.locktuple.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
## Kontext
Das Ereignis `Lock:tuple` zeigt an, dass ein Back-End darauf wartet, eine Sperre für ein Tupel zu erlangen, während ein anderes Back-End eine widersprüchliche Sperre für dasselbe Tupel hält. Die folgende Tabelle veranschaulicht ein Szenario, in dem Sitzungen das `Lock:tuple`-Ereignis generieren.
| Zeit | 1. Sitzung | 2. Sitzung | 3. Sitzung |
| --- | --- | --- | --- |
| t1 | Startet eine Transaktion. | | |
| t2 | Aktualisiert Zeile 1. | | |
| t3 | | Aktualisiert Zeile 1. Die Sitzung erwirbt eine exklusive Sperre für das Tupel und wartet dann darauf, dass Sitzung 1 die Sperre durch Commit oder Rollback freigibt. | |
| t4 | | | Aktualisiert Zeile 1. Die Sitzung wartet darauf, dass Sitzung 2 die exklusive Sperre für das Tupel freigibt. |
Oder Sie können dieses Warteereignis simulieren, indem Sie das Benchmarking-Tool `pgbench` verwenden. Konfigurieren Sie eine hohe Anzahl gleichzeitiger Sitzungen, um dieselbe Zeile in einer Tabelle mit einer benutzerdefinierten SQL-Datei zu aktualisieren.
Weitere Informationen zu widersprüchlichen Sperrmodi finden Sie unter [Explizite Sperren](https://www.postgresql.org/docs/current/explicit-locking.html) in der PostgreSQL-Dokumentation. Weitere Informationen zu `pgbench` finden Sie unter [pgbench](https://www.postgresql.org/docs/current/pgbench.html) in der PostgreSQL-Dokumentation.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn dieses Ereignis mehr als normal auftritt und möglicherweise auf ein Leistungsproblem hinweist, sind typische Ursachen:
+ Eine große Anzahl gleichzeitiger Sitzungen versucht, eine widersprüchliche Sperre für dasselbe Tupel zu erlangen, indem sie `UPDATE`- oder `DELETE`-Anweisungen ausführen.
+ In hochgradig gleichzeitigen Sitzungen wird eine `SELECT`-Anweisung ausgeführt, die den `FOR UPDATE`- oder `FOR NO KEY UPDATE`-Sperrmodus verwendet.
+ Verschiedene Faktoren veranlassen Anwendungs- oder Verbindungspools dazu, weitere Sitzungen zu öffnen, um dieselben Vorgänge auszuführen. Wenn neue Sitzungen versuchen, dieselben Zeilen zu ändern, kann die DB-Last stark ansteigen und `Lock:tuple` kann erscheinen.
Weitere Informationen finden Sie unter [Sperren auf Zeilenebene](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS) in der PostgreSQL-Dokumentation.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Untersuchen Sie Ihre Anwendungslogik](#apg-waits.locktuple.actions.problem)
+ [Finde die Blocker-Sitzung](#apg-waits.locktuple.actions.find-blocker)
+ [Reduzieren Sie Parallelität, wenn es hoch ist](#apg-waits.locktuple.actions.concurrency)
+ [Beheben von Engpässen](#apg-waits.locktuple.actions.bottlenecks)
### Untersuchen Sie Ihre Anwendungslogik
Finden Sie heraus, ob sich eine Blocker-Sitzung schon lange im `idle in transaction`-Zustand befindet. Wenn ja, erwägen Sie, die Blocker-Sitzung als kurzfristige Lösung zu beenden. Sie können die Funktion `pg_terminate_backend` verwenden. Weitere Informationen zu dieser Funktion finden Sie unter [Server-Signalisierungsfunktionen](https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL) in der PostgreSQL-Dokumentation.
Gehen Sie für eine langfristige Lösung wie folgt vor:
+ Passen Sie die Anwendungslogik an.
+ Verwenden Sie den Parameter `idle_in_transaction_session_timeout`. Dieser Parameter beendet jede Sitzung mit einer offenen Transaktion, die länger als die angegebene Zeitspanne im Leerlauf ist. Weitere Informationen finden Sie unter [Standardeinstellungen für Clientverbindungen](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT) in der PostgreSQL-Dokumentation.
+ Verwenden Sie Autocommit so weit wie möglich. Weitere Informationen finden Sie unter [SET AUTOCOMMIT](https://www.postgresql.org/docs/current/ecpg-sql-set-autocommit.html) in der PostgreSQL-Dokumentation.
### Finde die Blocker-Sitzung
Identifizieren Sie während des `Lock:tuple`-Wait-Ereignisses den Blocker und die blockierte Sitzung, indem Sie herausfinden, welche Sperren voneinander abhängen. Weitere Informationen finden Sie unter [Informationen zur Sperrabhängigkeit](https://wiki.postgresql.org/wiki/Lock_dependency_information) im PostgreSQL-Wiki. Um vergangene `Lock:tuple`-Ereignisse zu analysieren, verwenden Sie die Aurora-Funktion `aurora_stat_backend_waits`.
Im folgenden Beispiel werden alle Sitzungen abgefragt, nach `tuple` gefiltert und nach `wait_time` sortiert.
```
--AURORA_STAT_BACKEND_WAITS
SELECT a.pid,
a.usename,
a.app_name,
a.current_query,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
left(query,80) as current_query,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND usename<>'rdsadmin') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we
WHERE we.event_name = 'tuple'
ORDER BY a.wait_time;
pid | usename | app_name | current_query | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time
-------+---------+----------+------------------------------------------------+-------------------+--------------------+---------------+-----------+------------+-------+-----------
32136 | sys | psql | /*session3*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000018
11999 | sys | psql | /*session4*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000024
```
### Reduzieren Sie Parallelität, wenn es hoch ist
Das `Lock:tuple`-Ereignis kann ständig auftreten, insbesondere in einer arbeitsreichen Zeit. Erwägen Sie in dieser Situation, die hohe Parallelität für sehr belegte Reihen zu reduzieren. Oft steuern nur wenige Zeilen eine Warteschlange oder die boolesche Logik, was diese Zeilen sehr ausgelastet macht.
Sie können die Parallelität reduzieren, indem Sie verschiedene Ansätze verwenden, die auf der Geschäftsanforderung, der Anwendungslogik und dem Workload-Typ basieren. Sie können z. B. Folgendes tun:
+ Gestalten Sie Ihre Tabellen- und Datenlogik neu, um hohe Parallelität zu reduzieren.
+ Ändern Sie die Anwendungslogik, um die hohe Parallelität auf Zeilenebene zu reduzieren.
+ Nutzen und gestalten Sie Abfragen mit Sperren auf Zeilenebene.
+ Verwenden Sie die `NOWAIT`-Klausel mit Wiederholungsvorgänge.
+ Erwägen Sie, optimistische und hybridsperrende Logik-Parallelitätssteuerung zu nutzen.
+ Überlegen Sie, die Isolationsstufe der Datenbank zu ändern.
### Beheben von Engpässen
Das `Lock:tuple` kann bei Engpässen wie CPU-Aushungerungen oder maximaler Nutzung der Amazon EBS-Bandbreite auftreten. Um Engpässe zu verringern, sollten Sie die folgenden Ansätze berücksichtigen:
+ Skalieren Sie Ihren Instance-Klassentyp hoch.
+ Optimieren Sie ressourcenintensive Abfragen.
+ Ändern Sie die Anwendungslogik.
+ Archivieren Sie Daten, die selten zugegriffen wird.
# LWLock:buffer\$1content () BufferContent
Das Ereignis `LWLock:buffer_content` tritt ein, wenn eine Sitzung darauf wartet, eine Datenseite im Speicher zu lesen oder zu schreiben, während eine andere Sitzung diese Seite zum Schreiben gesperrt hat. In Aurora PostgreSQL 13 und höher heißt dieses Warteereignis `BufferContent`.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-waits.lockbuffercontent.context.supported)
+ [Kontext](#apg-waits.lockbuffercontent.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-waits.lockbuffercontent.causes)
+ [Aktionen](#apg-waits.lockbuffercontent.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
## Kontext
Um Daten zu lesen oder zu manipulieren, greift PostgreSQL über Shared Memory Puffer darauf zu. Um aus dem Puffer zu lesen, erhält ein Prozess im Shared-Modus eine einfache Sperre (LWLock) für den Pufferinhalt. Um in den Puffer zu schreiben, wird diese Sperre im exklusiven Modus angezeigt. Gemeinsame Sperren ermöglichen es anderen Prozessen, gleichzeitig gemeinsame Sperren für diesen Inhalt zu erwerben. Exklusive Sperren verhindern, dass andere Prozesse irgendeine Art von Sperre erhalten.
Das Ereignis `LWLock:buffer_content` (`BufferContent`) weist darauf hin, dass mehrere Prozesse versuchen, einfache Sperren (LWLocks) für den Inhalt eines bestimmten Puffers zu aktivieren.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `LWLock:buffer_content`(`BufferContent`)-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
**Die gleichzeitigen Aktualisierungen der gleichen Daten wurden erhöht**
Es kann zu einer Zunahme der Anzahl gleichzeitiger Sitzungen mit Abfragen kommen, die denselben Pufferinhalt aktualisieren. Diese Behauptung kann bei Tabellen mit vielen Indizes ausgeprägter sein.
**Workload-Daten befinden sich nicht im Speicher**
Wenn sich Daten, die die aktive Workload verarbeitet, nicht im Speicher befinden, können diese Warteereignisse zunehmen. Dieser Effekt ist darauf zurückzuführen, dass Prozesse, die Sperren enthalten, diese länger behalten können, während sie I/O Festplattenoperationen ausführen.
**Übermäßiger Einsatz von Fremdschlüsselbeschränkungen**
Fremdschlüsseleinschränkungen können die Zeit erhöhen, die ein Prozess an einer Pufferinhaltssperre hält. Dieser Effekt liegt daran, dass Lesevorgänge eine gemeinsame Pufferinhaltssperre für den referenzierten Schlüssel erfordern, während dieser Schlüssel aktualisiert wird.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. Sie können `LWLock:buffer_content`(`BufferContent`)-Ereignisse identifizieren, indem Sie Amazon RDS Performance Insights verwenden oder die Ansicht `pg_stat_activity` abfragen.
**Topics**
+ [Verbessern Sie die Effizienz im Speicher](#apg-waits.lockbuffercontent.actions.in-memory)
+ [Reduzieren Sie die Verwendung von Fremdschlüsselbeschränkungen](#apg-waits.lockbuffercontent.actions.foreignkey)
+ [Entferne nicht verwendete Indizes](#apg-waits.lockbuffercontent.actions.indexes)
+ [Entfernen von doppelten Indizes](#apg-waits.lockbuffercontent.actions.duplicate-indexes)
+ [Löschen oder NEU INDIZIEREN von ungültigen Indizes](#apg-waits.lockbuffercontent.actions.invalid-indexes)
+ [Verwenden von partiellen Indizes](#apg-waits.lockbuffercontent.actions.partial-indexes)
+ [Entfernen von überflüssigen Daten aus Tabellen und Indizes (Bloat)](#apg-waits.lockbuffercontent.actions.bloat)
### Verbessern Sie die Effizienz im Speicher
Um die Wahrscheinlichkeit zu erhöhen, dass sich aktive Workload-Daten im Speicher befinden, partitionieren Sie Tabellen oder skalieren Sie Ihre Instance-Klasse hoch. Weitere Informationen zu DB-Instance-Klassen finden Sie unter [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md).
Überwachen Sie die `BufferCacheHitRatio`-Metrik. Diese misst den Prozentsatz der Anfragen, die vom Puffer-Cache einer DB-Instance in Ihrem DB-Cluster verarbeitet werden. Diese Metrik gibt Aufschluss über die Datenmenge, die vom Speicher bereitgestellt wird. Eine hohe Trefferrate bedeutet, dass Ihre DB-Instance über ausreichend Speicherplatz für Ihren Arbeitsdatensatz verfügt, während eine niedrige Trefferrate darauf hindeutet, dass Ihre Abfragen häufig auf Daten aus dem Speicher zugreifen.
Die Cache-Lesetreffer pro Tabelle und die Cache-Lesetreffer pro Index im Abschnitt zu den Speichereinstellungen des [PG-Collector](https://github.com/awslabs/pg-collector)-Berichts können Aufschluss über die Cache-Trefferrate von Tabellen und Indizes geben.
### Reduzieren Sie die Verwendung von Fremdschlüsselbeschränkungen
Untersuchen Sie Workloads, bei denen eine hohe Anzahl von `LWLock:buffer_content`(`BufferContent`)-Wait-Ereignissen auf die Verwendung von Fremdschlüsseleinschränkungen auftritt. Entfernen Sie unnötige Fremdschlüsselbeschränkungen.
### Entferne nicht verwendete Indizes
Identifizieren Sie bei Workloads mit einer hohen Anzahl von `LWLock:buffer_content`(`BufferContent`)-Wait-Ereignissen nicht verwendete Indizes und entfernen Sie sie.
Der Abschnitt zu nicht genutzten Indizes im [PG-Collector](https://github.com/awslabs/pg-collector)-Bericht kann Aufschluss über die nicht genutzten Indizes in der Datenbank geben.
### Entfernen von doppelten Indizes
Identifizieren Sie doppelte Indizes und entfernen Sie sie.
Der Abschnitt zu doppelten Indizes im [PG-Collector](https://github.com/awslabs/pg-collector)-Bericht kann Aufschluss über die doppelten Indizes in der Datenbank geben.
### Löschen oder NEU INDIZIEREN von ungültigen Indizes
Ungültige Indizes kommen in der Regel vor, wenn `CREATE INDEX CONCURRENTLY` oder `REINDEX CONCURRENTLY` verwendet wird und der Befehl fehlschlägt oder abgebrochen wird.
Ungültige Indizes können nicht für Abfragen verwendet werden, werden aber trotzdem aktualisiert und beanspruchen Speicherplatz.
Der Abschnitt zu ungültigen Indizes im [PG-Collector](https://github.com/awslabs/pg-collector)-Bericht kann Aufschluss über ungültige Indizes in der Datenbank geben.
### Verwenden von partiellen Indizes
Partielle Indizes können verwendet werden, um die Abfrageleistung zu verbessern und die Indexgröße zu reduzieren. Ein partieller Index ist ein Index, der auf einer Teilmenge einer Tabelle basiert, wobei die Teilmenge durch einen bedingten Ausdruck definiert ist. Wie in der [partial index](https://www.postgresql.org/docs/current/indexes-partial.html)-Dokumentation beschrieben, können partielle Indizes den Aufwand für die Verwaltung von Indizes reduzieren, da PostgreSQL den Index nicht in jedem Fall aktualisieren muss.
### Entfernen von überflüssigen Daten aus Tabellen und Indizes (Bloat)
Ein übermäßiger Tabellen- und Index-Bloat kann sich negativ auf die Datenbankleistung auswirken. Tabellen und Indizes, die viel überflüssige Daten enthalten, erhöhen die Größe des aktiven Arbeitssatzes, wodurch die Effizienz im Arbeitsspeicher beeinträchtigt wird. Darüber hinaus erhöhen überflüssige Daten die Speicherkosten und verlangsamen die Ausführung von Abfragen. Informationen zur Bloat-Diagnose finden Sie unter [Diagnostizieren einer Überlastung von Tabellen und Indizes](AuroraPostgreSQL.diag-table-ind-bloat.md). Darüber hinaus gibt der Abschnitt zur Fragmentierung (Bloat) im [PG-Collector](https://github.com/awslabs/pg-collector)-Bericht Aufschluss über Tabellen und Indizes mit überflüssigen Daten.
Zur Behebung des Problems der überflüssigen Daten in Tabellen und Indizes gibt es einige Optionen:
**VACUUM FULL**
`VACUUM FULL` erstellt eine neue Kopie der Tabelle, wobei nur die aktiven Tupel kopiert werden, und ersetzt dann die alte Tabelle durch die neue, wobei eine `ACCESS EXCLUSIVE`-Sperre beibehalten wird. Dadurch wird jegliches Lesen oder Schreiben in die Tabelle verhindert, was zu einem Ausfall führen kann. Außerdem dauert `VACUUM FULL` länger, wenn die Tabelle groß ist.
**pg\$1repack**
`pg_repack` ist hilfreich in Situationen, in denen `VACUUM FULL` möglicherweise nicht geeignet ist. Es erstellt eine neue Tabelle, die die Daten der Tabelle mit den überflüssigen Daten enthält, verfolgt die Änderungen gegenüber der Originaltabelle nach und ersetzt diese Tabelle dann durch die neue. Es sperrt die Originaltabelle nicht für Lese- oder Schreibvorgänge, während die neue Tabelle erstellt wird. Weitere Informationen zur Verwendung von `pg_repack` finden Sie unter [Reduzieren von überflüssigen Daten mit pg\$1repack](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/pg-repack.html) und unter [pg\$1repack](https://reorg.github.io/pg_repack/).
**REINDEX**
Der `REINDEX`-Befehl kann genutzt werden, um das Problem eines Index-Bloat zu beheben. `REINDEX` schreibt eine neue Version des Index ohne die „toten“ oder leeren bzw. fast leeren Seiten, was den Platzverbrauch des Index reduziert. Detaillierte Informationen zum [https://www.postgresql.org/docs/current/sql-reindex.html](https://www.postgresql.org/docs/current/sql-reindex.html)-Befehl finden Sie in der REINDEX-Dokumentation.
Nach dem Entfernen der überflüssigen Daten aus Tabellen und Indizes kann es notwendig sein, die Selbstbereinigungsfrequenzen für diese Tabellen zu erhöhen. Die Implementierung von Einstellungen für eine aggressive Selbstbereinigung auf Tabellenebene kann dazu beitragen, überflüssige Daten zu vermeiden. Weitere Informationen finden Sie in der Dokumentation über [https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html).
# LWLock:buffer\$1mapping
Dieses Ereignis tritt ein, wenn eine Sitzung darauf wartet, einen Datenblock einem Puffer im gemeinsam genutzten Pufferpool zuzuordnen.
**Anmerkung**
Dieses Ereignis wird in Aurora PostgreSQL Version 12 und niedriger als `LWLock:buffer_mapping` und in Version 13 und höher als `LWLock:BufferMapping` angezeigt.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-waits.lwl-buffer-mapping.context.supported)
+ [Kontext](#apg-waits.lwl-buffer-mapping.context)
+ [Ursachen](#apg-waits.lwl-buffer-mapping.causes)
+ [Aktionen](#apg-waits.lwl-buffer-mapping.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen sind für Aurora PostgreSQL Version 9.6 und höher relevant.
## Kontext
Der *freigegebene Pufferpool* ist ein Aurora PostgreSQL-Speicherbereich, der alle Seiten enthält, die von Prozessen verwendet werden oder wurden. Wenn ein Prozess eine Seite benötigt, liest er die Seite in den freigegebenen Pufferpool. Der Parameter `shared_buffers` legt die Größe des gemeinsam genutzten Puffers fest und reserviert einen Speicherbereich zum Speichern der Tabellen- und Indexseiten. Wenn Sie diesen Parameter ändern, stellen Sie sicher, dass Sie die Datenbank neu starten. Weitere Informationen finden Sie unter [Freigegebene Puffer](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.buffer-pool).
Das `LWLock:buffer_mapping`-Wait-Ereignis tritt in den folgenden Szenarien auf:
+ Ein Prozess durchsucht die Puffertabelle nach einer Seite und erwirbt eine freigegebene Puffer-Mapping-Sperre.
+ Ein Prozess lädt eine Seite in den Pufferpool und erwirbt eine exklusive Puffer-Mapping-Sperre.
+ Ein Prozess entfernt eine Seite aus dem Pool und erwirbt eine exklusive Puffer-Mapping-Sperre.
## Ursachen
Wenn dieses Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, greift die Datenbank in und aus dem freigegebenen Pufferpool aus. Zu den typischen Ursachen zählen auch die Folgenden:
+ Große Abfragen
+ Aufgeblähte Indizes und Tabellen
+ Vollständige Tabellenscans
+ Eine gemeinsame Poolgröße, die kleiner als der Arbeitssatz ist
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Überwachen Sie pufferbezogene Metriken](#apg-waits.lwl-buffer-mapping.actions.monitor-metrics)
+ [Bewerten Sie Ihre Indexierungsstrategie](#apg-waits.lwl-buffer-mapping.actions.indexes)
+ [Reduzieren Sie die Anzahl der Puffer, die schnell zugewiesen werden müssen](#apg-waits.lwl-buffer-mapping.actions.buffers)
### Überwachen Sie pufferbezogene Metriken
Wenn `LWLock:buffer_mapping` auf Spitze wartet, untersuchen Sie die Puffertrefferquote. Sie können diese Metriken verwenden, um ein besseres Verständnis dafür zu erhalten, was im Puffer-Cache passiert. Untersuchen Sie die folgenden Metriken:
`BufferCacheHitRatio`
Diese CloudWatch Amazon-Metrik misst den Prozentsatz der Anfragen, die vom Puffer-Cache einer DB-Instance in Ihrem DB-Cluster bedient werden. Möglicherweise sehen Sie diese Metrikabnahme im Vorfeld des `LWLock:buffer_mapping`-Wait-Ereignisses.
`blks_hit`
Diese Zählermetrik für Performance Insights gibt die Anzahl der Blöcke an, die aus dem freigegebenen Pufferpool abgerufen wurden. Nachdem das Wait-Ereignis `LWLock:buffer_mapping` aufgetreten ist, können Sie eine Spitze in `blks_hit` beobachten.
`blks_read`
Diese Performance Insights Insights-Zählermetrik gibt die Anzahl der Blöcke I/O an, die in den gemeinsam genutzten Pufferpool eingelesen werden mussten. Sie können im Vorfeld des `LWLock:buffer_mapping`-Warteereignisses eine Spitze in `blks_read` beobachten.
### Bewerten Sie Ihre Indexierungsstrategie
Überprüfen Sie Folgendes, um zu bestätigen, dass Ihre Indexierungsstrategie die Leistung nicht beeinträchtigt:
Indexblähung
Stellen Sie sicher, dass Index und Tabellenaufblähungen nicht dazu führen, dass unnötige Seiten in den freigegebenen Puffer gelesen werden. Wenn Ihre Tabellen nicht verwendete Zeilen enthalten, sollten Sie die Daten archivieren und die Zeilen aus den Tabellen entfernen. Sie können dann die Indizes für die skalierten Tabellen neu erstellen.
Indizes für häufig verwendete Abfragen
Um festzustellen, ob Sie über die optimalen Indizes verfügen, überwachen Sie die Metriken der DB-Engine in Performance Insights. Die `tup_returned`-Metrik zeigt die Anzahl der gelesenen Zeilen an. Die `tup_fetched`-Metrik zeigt die Anzahl der an den Client zurückgegebenen Zeilen. Wenn `tup_returned` deutlich größer als `tup_fetched` ist, werden die Daten möglicherweise nicht richtig indiziert. Außerdem sind Ihre Tabellenstatistiken möglicherweise nicht aktuell.
### Reduzieren Sie die Anzahl der Puffer, die schnell zugewiesen werden müssen
Um die `LWLock:buffer_mapping`-Warteereignisse zu reduzieren, versuchen Sie, die Anzahl der Puffer zu reduzieren, die schnell zugewiesen werden müssen. Eine Strategie besteht darin, kleinere Batch-Vorgänge durchzuführen. Möglicherweise können Sie kleinere Batches erreichen, indem Sie Ihre Tabellen partitionieren.
# LWLock:BufferIO (IPC:BufferIO)
Das `LWLock:BufferIO`-Ereignis tritt ein, wenn Aurora PostgreSQL oder RDS for PostgreSQL darauf wartet, dass andere Prozesse ihre Eingabe-/Ausgabe-(I/O)-Vorgänge beenden, wenn sie gleichzeitig versuchen, auf eine Seite zuzugreifen. Sein Zweck besteht darin, dass dieselbe Seite in den freigegebenen Puffer eingelesen wird.
**Topics**
+ [Relevante Engine-Versionen](#apg-waits.lwlockbufferio.context.supported)
+ [Kontext](#apg-waits.lwlockbufferio.context)
+ [Ursachen](#apg-waits.lwlockbufferio.causes)
+ [Aktionen](#apg-waits.lwlockbufferio.actions)
## Relevante Engine-Versionen
Diese Warteereignisinformationen sind für alle Versionen von Aurora PostgreSQL. Für Aurora PostgreSQL 12 und frühere Versionen wird dieses Warteereignis als lwlock:buffer\$1io bezeichnet, während es in der Version Aurora PostgreSQL 13 den Namen lwlock:bufferio trägt. Aus der Version Aurora PostgreSQL 14 wurde das BufferIO-Warteereignis von `LWLock` zum Warteereignistyp `IPC` (ipc:bufferio) verschoben.
## Kontext
Jeder gemeinsam genutzte Puffer hat eine I/O-Sperre, die mit dem `LWLock:BufferIO`-Warteereignis verbunden ist, jedes Mal, wenn ein Block (oder eine Seite) außerhalb des gemeinsam genutzten Pufferpools abgerufen werden muss.
Diese Sperre wird verwendet, um mehrere Sitzungen zu behandeln, die alle Zugriff auf denselben Block benötigen. Dieser Block muss von außerhalb des gemeinsam genutzten Pufferpools gelesen werden, der durch den `shared_buffers`-Parameter definiert wird.
Sobald die Seite innerhalb des Shared Buffer Pool gelesen wird, wird die `LWLock:BufferIO`-Sperre freigegeben.
**Anmerkung**
Das `LWLock:BufferIO`-Wait-Ereignis geht dem [IO: DataFileRead](apg-waits.iodatafileread.md)-Warteereignis voraus. Das `IO:DataFileRead`-Wait-Ereignis tritt auf, während Daten aus dem Speicher gelesen werden.
Weitere Informationen zu leichten Sperren finden Sie unter [Übersicht über Sperren](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).
## Ursachen
Häufige Gründe dafür, dass das `LWLock:BufferIO`-Ereignis in den Top-Wartezeiten angezeigt wird, sind die folgenden:
+ Mehrere Backends oder Verbindungen, die versuchen, auf dieselbe Seite zuzugreifen, für die auch ein I/O-Vorgang aussteht
+ Das Verhältnis zwischen der Größe des gemeinsam genutzten Pufferpools (definiert durch den `shared_buffers`-Parameter) und der Anzahl der Puffer, die von der aktuellen Workload benötigt werden
+ Die Größe des freigegebenen Pufferpools ist nicht gut mit der Anzahl der Seiten, die durch andere Vorgänge geräumt werden
+ Große oder aufgeblähte Indizes, bei denen die Engine mehr Seiten als nötig in den freigegebenen Pufferpool lesen muss
+ Mangel an Indizes, die die DB-Engine dazu zwingen, mehr Seiten aus den Tabellen als nötig zu lesen
+ Plötzliche Spitzen für Datenbankverbindungen, die versuchen, Vorgänge auf derselben Seite auszuführen
## Aktionen
Abhängig von den Ursachen Ihres Wait-Ereignisses empfehlen wir verschiedene Aktionen:
+ Beobachten Sie die Amazon CloudWatch-Metriken auf Korrelation zwischen starken Abnahmen der `BufferCacheHitRatio`- und `LWLock:BufferIO`-Warteereignisse. Dieser Effekt kann bedeuten, dass Sie eine kleine Einstellung für gemeinsame Puffer haben. Möglicherweise müssen Sie es erhöhen oder Ihre DB-Instance-Klasse hochskalieren. Sie können Ihre Workload in mehr Reader-Knoten aufteilen.
+ Überprüfen Sie, ob Sie nicht verwendete Indizes haben, und entfernen Sie sie dann.
+ Verwenden Sie partitionierte Tabellen (die auch partitionierte Indizes haben). Dies hilft, die Neuordnung des Index niedrig zu halten und ihre Auswirkungen zu reduzieren.
+ Vermeiden Sie, Spalten unnötig zu indizieren.
+ Verhindern Sie plötzliche Spitzen der Datenbankverbindung, indem Sie einen Verbindungspool verwenden.
+ Beschränken Sie die maximale Anzahl von Verbindungen zur Datenbank als bewährte Methode
# LWLock:lock\$1manager
Dieses Ereignis tritt ein, wenn die Aurora PostgreSQL-Engine den Speicherbereich der gemeinsam genutzten Sperre verwaltet, um eine Sperre zuzuweisen, zu überprüfen und aufzuheben, wenn eine Fast-Path-Sperre nicht möglich ist.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-waits.lw-lock-manager.context.supported)
+ [Kontext](#apg-waits.lw-lock-manager.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-waits.lw-lock-manager.causes)
+ [Aktionen](#apg-waits.lw-lock-manager.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen sind für Aurora PostgreSQL Version 9.6 und höher relevant.
## Kontext
Wenn Sie eine SQL-Anweisung ausgeben, zeichnet Aurora PostgreSQL Sperren auf, um die Struktur, Daten und Integrität Ihrer Datenbank während gleichzeitiger Vorgänge zu schützen. Der Motor kann dieses Ziel mit einer schnellen Pfadsperre oder einer nicht schnellen Pfadsperre erreichen. Eine Pfadsperre, die nicht schnell ist, ist teurer und erzeugt mehr Overhead als eine schnelle Pfadsperre.
### Schnelle Pfadsperre
Um den Overhead von Sperren zu reduzieren, die häufig genommen und freigegeben werden, aber selten in Konflikt geraten, können Backend-Prozesse eine schnelle Pfadsperrung verwenden. Die Datenbank verwendet diesen Mechanismus für Sperren, die die folgenden Kriterien erfüllen:
+ Sie verwenden die STANDARD–Sperrmethode.
+ Sie stellen eine Sperre für eine Datenbankbeziehung statt einer gemeinsamen Beziehung dar.
+ Sie sind schwache Sperren, die wahrscheinlich nicht in Konflikt stehen.
+ Die Engine kann schnell überprüfen, dass keine widersprüchlichen Sperren existieren können.
Die Engine kann keine schnelle Pfadsperre verwenden, wenn eine der folgenden Bedingungen erfüllt ist:
+ Die Sperre erfüllt nicht die vorhergehenden Kriterien.
+ Für den Backend-Prozess sind keine Slots mehr verfügbar.
Weitere Informationen zum Sperren von Fast Path finden Sie unter [Fast Path](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76) in der README-Datei des PostgreSQL-Sperrmanagers und unter [pg-locks](https://www.postgresql.org/docs/15/view-pg-locks.html) in der PostgreSQL-Dokumentation.
### Beispiel für ein Skalierungsproblem für den Sperrmanager
In diesem Beispiel speichert eine Tabelle mit dem Namen `purchases` Daten aus fünf Jahren, aufgeteilt nach Tagen. Jede Partition hat zwei Indizes. Die folgende Abfolge von Ereignissen tritt auf:
1. Sie fragen Daten für viele Tage ab, wodurch die Datenbank viele Partitionen lesen muss.
1. Die Datenbank erstellt einen Sperreintrag für jede Partition. Wenn Partitionsindizes Teil des Optimizer-Zugriffspfads sind, erstellt die Datenbank auch für sie einen Sperreintrag.
1. Wenn die Anzahl der angeforderten Sperreneinträge für denselben Backend-Prozess höher als 16 ist, was dem Wert von `FP_LOCK_SLOTS_PER_BACKEND` entspricht, verwendet der Sperrenmanager die Sperrmethode ohne Fast Path.
Moderne Anwendungen haben möglicherweise Hunderte von Sitzungen. Wenn gleichzeitige Sitzungen das übergeordnete Element ohne ordnungsgemäßen Schnitt von Partitionen abfragen, erstellt die Datenbank möglicherweise Hunderte oder sogar Tausende von nicht schnellen Pfadsperren. Wenn diese Parallelität höher als die Anzahl von v istCPUs, tritt normalerweise das Wait-Ereignis auf`LWLock:lock_manager`.
**Anmerkung**
Das Wait-Ereignis `LWLock:lock_manager` hat nichts mit der Anzahl der Partitionen oder Indizes in einem Datenbankschema zu tun. Stattdessen hängt es mit der Anzahl der nicht schnellen Pfadsperren zusammen, die die Datenbank steuern muss.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `LWLock:lock_manager` häufiger als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die wahrscheinlichsten Ursachen für plötzliche Spitzen wie folgt:
+ Gleichzeitige aktive Sitzungen führen Abfragen aus, die keine schnellen Pfadsperren verwenden. Diese Sitzungen überschreiten auch die maximale vCPU.
+ Eine große Anzahl gleichzeitiger aktiver Sitzungen greift auf eine stark partitionierte Tabelle zu. Jede Partition hat mehrere Indizes.
+ Die Datenbank erlebt einen Verbindungssturm. Standardmäßig erzeugen einige Anwendungen und Connection Pool-Software mehr Verbindungen, wenn die Datenbank langsam ist. Diese Praxis verschlimmert das Problem. Optimieren Sie Ihre Connection Pool-Software so, dass keine Verbindungsstürme auftreten.
+ Eine große Anzahl von Sitzungen fragt eine übergeordnete Tabelle ab, ohne Partitionen zu beschneiden.
+ Eine Datendefinitionssprache (DDL), Datenmanipulationssprache (DML) oder ein Wartungsbefehl sperrt ausschließlich eine Beleg-Beziehung oder Tupel, auf die häufig zugegriffen oder geändert werden.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Verwenden Sie das Beschneiden von Partitionen](#apg-waits.lw-lock-manager.actions.pruning)
+ [Entfernen unnötiger Indizes](#apg-waits.lw-lock-manager.actions.indexes)
+ [Optimieren Sie Ihre Abfragen für schnelles Pfadsperren](#apg-waits.lw-lock-manager.actions.tuning)
+ [Tune auf andere Warteereignisse](#apg-waits.lw-lock-manager.actions.other-waits)
+ [Reduzieren von Hardware-Engpässen](#apg-waits.lw-lock-manager.actions.hw-bottlenecks)
+ [Verwenden eines Verbindungs-Poolers](#apg-waits.lw-lock-manager.actions.pooler)
+ [Aktualisieren Sie Ihre Aurora PostgreSQL Version](#apg-waits.lw-lock-manager.actions.pg-version)
### Verwenden Sie das Beschneiden von Partitionen
Die *Partitionsbereinigung* ist eine Strategie zur Abfrageoptimierung, die nicht benötigte Partitionen von Tabellenscans ausschließt und dadurch die Leistung verbessert. Das Beschneiden der Partition ist standardmäßig aktiviert. Wenn es ausgeschaltet ist, schalten Sie es wie folgt ein.
```
SET enable_partition_pruning = on;
```
Abfragen können die Partitionsbereinigung nutzen, wenn ihre `WHERE`-Klausel die für die Partitionierung verwendete Spalte enthält. Weitere Informationen finden Sie unter [Partitionsbereinigung](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING) in der PostgreSQL-Dokumentation.
### Entfernen unnötiger Indizes
Ihre Datenbank enthält möglicherweise nicht verwendete oder selten verwendete Indizes. Wenn ja, erwägen Sie, sie zu löschen. Führen Sie eine der folgenden Aufgaben aus:
+ Erfahren Sie, wie Sie unnötige Indizes finden, indem Sie [Ungenutzte Indizes](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes) im PostgreSQL-Wiki lesen.
+ Führen Sie PG Collector aus. Dieses SQL-Skript sammelt Datenbankinformationen und präsentiert sie in einem konsolidierten HTML-Bericht. Überprüfen Sie den Abschnitt „Unbenutzte Indizes“. Weitere Informationen finden Sie unter [pg-collector im Labs-Repository](https://github.com/awslabs/pg-collector). AWS GitHub
### Optimieren Sie Ihre Abfragen für schnelles Pfadsperren
Um herauszufinden, ob Ihre Abfragen Fast Path Locking verwenden, fragen Sie die `fastpath`-Spalte in der `pg_locks`-Tabelle ab. Wenn Ihre Abfragen keine schnelle Pfadsperre verwenden, versuchen Sie, die Anzahl der Beziehungen pro Abfrage auf weniger als 16 zu reduzieren.
### Tune auf andere Warteereignisse
Wenn `LWLock:lock_manager` in der Liste der Top-Waits an erster oder zweiter Stelle steht, überprüfen Sie, ob die folgenden Wait-Ereignisse auch in der Liste erscheinen:
+ `Lock:Relation`
+ `Lock:transactionid`
+ `Lock:tuple`
Wenn die vorhergehenden Ereignisse in der Liste hoch erscheinen, sollten Sie zuerst diese Warteereignisse optimieren. Diese Ereignisse können ein Treiber für `LWLock:lock_manager`.
### Reduzieren von Hardware-Engpässen
Möglicherweise haben Sie einen Hardware-Engpass wie CPU-Hunger oder maximale Auslastung Ihrer Amazon EBS-Bandbreite. Ziehen Sie in diesen Fällen die Verringerung der Hardware-Engpässe in Betracht. Berücksichtigen Sie die folgenden Aktionen:
+ Skalieren Sie Ihre Instance-Klasse hoch.
+ Optimieren Sie Abfragen, die große Mengen an CPU und Speicher verbrauchen.
+ Ändern Sie Ihre Anwendungslogik.
+ Archiviere deine Daten.
Weitere Informationen zu CPU, Arbeitsspeicher und EBS-Netzwerkbandbreite finden Sie unter [Amazon-RDS-Instance-Typen](https://aws.amazon.com/rds/instance-types/).
### Verwenden eines Verbindungs-Poolers
Wenn Ihre Gesamtzahl aktiver Verbindungen die maximale vCPU überschreitet, benötigen mehr Betriebssystemprozesse CPU, als Ihr Instance-Typ unterstützen kann. Ziehen Sie in diesem Fall die Verwendung oder Abstimmung eines Verbindungspool in Betracht. Weitere Informationen über das v CPUs für Ihren Instance-Typ finden Sie unter [Amazon RDS-Instance-Typen](https://aws.amazon.com/rds/instance-types/).
Weitere Informationen zum Verbindungspooling finden Sie in den folgenden Ressourcen:
+ [Amazon RDS-Proxy für Aurora](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ [Verbindungspools und Datenquellen](https://www.postgresql.org/docs/7.4/jdbc-datasource.html) in der *PostgreSQL-Dokumentation*
### Aktualisieren Sie Ihre Aurora PostgreSQL Version
Wenn Ihre aktuelle Version von Aurora PostgreSQL niedriger als 12 ist, aktualisieren Sie auf Version 12 oder höher. PostgreSQL Versionen 12 und 13 haben einen verbesserten Partitionsmechanismus. Weitere Informationen zu Version 12 finden Sie in den [Versionshinweisen zu PostgreSQL 12.0]( https://www.postgresql.org/docs/release/12.0/). Weitere Informationen zum Aktualisieren von Aurora PostgreSQL finden Sie unter [Aktualisierungen der Datenbank-Engine für Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md).
# LWLock:MultiXact
Die Warteereignisse `LWLock:MultiXactMemberBuffer`, `LWLock:MultiXactOffsetBuffer`, `LWLock:MultiXactMemberSLRU` und `LWLock:MultiXactOffsetSLRU` geben an, dass eine Sitzung darauf wartet, eine Liste von Transaktionen abzurufen, die dieselbe Zeile in einer bestimmten Tabelle ändern.
+ `LWLock:MultiXactMemberBuffer` – Ein Prozess wartet auf I/O in einem einfachen, am wenigsten zuletzt verwendeten (SLRU) Puffer für ein Multixact-Mitglied.
+ `LWLock:MultiXactMemberSLRU` – Ein Prozess wartet darauf, auf den einfachen, am wenigsten zuletzt verwendeten (SLRU) Cache für ein Multixact-Mitglied zuzugreifen.
+ `LWLock:MultiXactOffsetBuffer` – Ein Prozess wartet auf I/O in einem einfachen, am wenigsten zuletzt verwendeten (SLRU) Puffer für ein Multixact-Offset.
+ `LWLock:MultiXactOffsetSLRU` – Ein Prozess wartet darauf, auf den einfachen, am wenigsten zuletzt verwendeten (SLRU) Cache für ein Multixact-Offset zuzugreifen.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-waits.xactsync.context.supported)
+ [Kontext](#apg-waits.lwlockmultixact.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-waits.lwlockmultixact.causes)
+ [Aktionen](#apg-waits.lwlockmultixact.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
## Kontext
*Multixact* ist eine Datenstruktur, die eine Liste von Transaktions-IDs (XIDs) speichert, welche dieselbe Tabellenzeile ändern. Wenn eine einzelne Transaktion auf eine Zeile in einer Tabelle verweist, wird die Transaktions-ID in der Kopfzeile der Tabelle gespeichert. Verweisen mehrere Transaktionen auf dieselbe Zeile in einer Tabelle, wird die Liste der Transaktions-IDs in der Multixact-Datenstruktur gespeichert. Die Multixact-Warteereignisse geben an, dass eine Sitzung die Liste der Transaktionen, die sich auf eine bestimmte Zeile in einer Tabelle beziehen, aus der Datenstruktur abruft.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
3 häufige Ursachen für die Verwendung von Multixact sind die folgenden:
+ **Untertransaktionen expliziter Savepoints** – Wenn Sie explizit einen Savepoint in Ihren Transaktionen erstellen, werden neue Transaktionen für dieselbe Zeile generiert. Verwenden Sie beispielsweise `SELECT FOR UPDATE`, `SAVEPOINT` und dann `UPDATE`.
Einige Treiber, objektrelationale Mappers (ORMs) und Abstraktionsschichten verfügen über Konfigurationsoptionen, um alle Operationen automatisch mit Savepoints zu umschließen. Dies kann bei einigen Workloads zu vielen Multixact-Warteereignissen führen. Die `autosave`-Option des PostgreSQL-JDBC-Treibers ist ein Beispiel dafür. Weitere Informationen finden Sie unter [pgJDBC](https://jdbc.postgresql.org/) in der PostgreSQL-JDBC-Dokumentation. Ein anderes Beispiel ist der PostgreSQL-ODBC-Treiber und seine `protocol`-Option. Weitere Informationen finden Sie unter [psqlODBC-Konfigurationsoptionen](https://odbc.postgresql.org/docs/config.html) in der Dokumentation zu PostgreSQL-ODBC-Treibern.
+ **Untertransaktionen von PL/pgSQL-EXCEPTION-Klauseln** – Jede `EXCEPTION`-Klausel, die Sie in Ihren PL/pgSQL-Funktionen oder -Prozeduren schreiben, erstellt intern einen `SAVEPOINT`.
+ **Fremdschlüssel** – Mehrere Transaktionen erwerben eine Freigabesperre für den übergeordneten Datensatz.
Wenn eine bestimmte Zeile in einer Operation mit mehreren Transaktionen enthalten ist, müssen für die Verarbeitung der Zeile die Transaktions-IDs aus den `multixact`-Auflistungen abgerufen werden. Wenn durch Lookups der Multixact nicht aus dem Speichercache abgerufen werden kann, muss die Datenstruktur aus der Aurora-Speicherschicht gelesen werden. Dieser I/O-Vorgang aus dem Speicher bedeutet, dass SQL-Abfragen länger dauern können. Speicher-Cache-Fehler können bei starker Auslastung aufgrund einer großen Anzahl von mehreren Transaktionen auftreten. All diese Faktoren tragen zu einer Zunahme dieses Warteereignisses bei.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. Einige dieser Aktionen können dazu beitragen, die Warteereignisse sofort zu reduzieren. Andere erfordern jedoch möglicherweise eine Untersuchung und Korrektur, um Ihren Workload zu skalieren.
**Topics**
+ [Durchführen einer Bereinigungseinfrierung auf Tabellen mit diesem Warteereignis](#apg-waits.lwlockmultixact.actions.vacuumfreeze)
+ [Erhöhen der Häufigkeit der Selbstbereinigung in Tabellen mit diesem Warteereignis](#apg-waits.lwlockmultixact.actions.autovacuum)
+ [Erhöhen der Speicherparameter](#apg-waits.lwlockmultixact.actions.memoryparam)
+ [Reduzieren von Transaktionen mit langer Laufzeit](#apg-waits.lwlockmultixact.actions.longtransactions)
+ [Langfristige Aktionen](#apg-waits.lwlockmultixact.actions.longactions)
### Durchführen einer Bereinigungseinfrierung auf Tabellen mit diesem Warteereignis
Wenn die Anzahl dieses Warteereignisses plötzlich stark ansteigt und sich auf Ihre Produktionsumgebung auswirkt, können Sie eine der folgenden temporären Methoden verwenden, um die Anzahl zu reduzieren.
+ Verwenden Sie *VACUUM FREEZE* für die betroffene Tabelle oder Tabellenpartition, um das Problem sofort zu beheben. Weitere Informationen finden Sie unter [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html).
+ Verwenden Sie die Klausel VACUUM (FREEZE, INDEX\$1CLEANUP FALSE), um eine schnelle Bereinigung durch Überspringen von Indizes durchzuführen. Weitere Informationen finden Sie unter [Möglichst schnelles Bereinigen einer Tabelle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing).
### Erhöhen der Häufigkeit der Selbstbereinigung in Tabellen mit diesem Warteereignis
Nach dem Scannen aller Tabellen in allen Datenbanken entfernt die VACUUM-Operation schließlich Multixacts, wobei die ältesten Multixact-Werte weiterverwendet werden. Weitere Informationen finden Sie unter [Multixacts und Wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-MULTIXACT-WRAPAROUND). Um die LWLock:MultiXact-Warteereignisse auf ein Minimum zu beschränken, müssen Sie den VACUUM-Prozess so oft wie nötig ausführen. Stellen Sie dazu sicher, dass der VACUUM-Prozess in Ihrem Aurora PostgreSQL-DB-Cluster optimal konfiguriert ist.
Wenn die Verwendung von VACUUM FREEZE für die betroffene Tabelle oder Tabellenpartition das Problem mit dem Warteereignis behebt, empfehlen wir, einen Scheduler wie `pg_cron` für die VACUUM-Durchführung zu verwenden, anstatt den Selbstbereinigung auf Instance-Ebene anzupassen.
Damit die Selbstbereinigung häufiger stattfindet, können Sie den Wert des `autovacuum_multixact_freeze_max_age`-Speicherparameters in der betroffenen Tabelle reduzieren. Weitere Informationen finden Sie unter [autovacuum\$1multixact\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MULTIXACT-FREEZE-MAX-AGE).
### Erhöhen der Speicherparameter
Sie können die Speichernutzung für Multixact-Caches optimieren, indem Sie die folgenden Parameter anpassen. Diese Einstellungen steuern, wie viel Speicher für diese Caches reserviert wird. Dies kann dazu beitragen, Multixact-Warteereignisse in Ihrem Workload zu reduzieren. Wir empfehlen, mit den folgenden Werten zu beginnen:
Für Aurora PostgreSQL 17 und höher:
+ `multixact_offset_buffers` = 128
+ `multixact_member_buffers` = 256
Für Aurora PostgreSQL 16 und niedriger:
+ `multixact_offsets_cache_size` = 128
+ `multixact_members_cache_size` = 256
**Anmerkung**
In Aurora PostgreSQL 17 wurden Parameternamen von `multixact_offsets_cache_size` in `multixact_offset_buffers` und von `multixact_members_cache_size` in `multixact_member_buffers` geändert, um sie an die Community von PostgreSQL 17 anzupassen.
Sie können diese Parameter auf Cluster-Ebene festlegen, sodass alle Instances in Ihrem Cluster konsistent bleiben. Wir empfehlen Ihnen, die Werte zu testen und anzupassen, damit sie Ihren spezifischen Workload-Anforderungen und Ihrer Instance-Klasse optimal entsprechen. Sie müssen die Writer-Instance neu starten, damit die Parameteränderung wirksam wird.
Die Parameter werden in Form von Multixact-Cache-Einträgen ausgedrückt. Jeder Cache-Eintrag belegt Speicherplatz Höhe von `8 KB`. Um den gesamten reservierten Speicher zu berechnen, multiplizieren Sie jeden Parameterwert mit `8 KB`. Wenn Sie beispielsweise einen Parameter auf 128 setzen, beträgt der gesamte reservierte Speicher `128 * 8 KB = 1 MB`.
### Reduzieren von Transaktionen mit langer Laufzeit
Transaktionen mit langer Laufzeit führen dazu, dass der Bereinigungsprozess Informationen beibehält, bis die Transaktion bestätigt oder die schreibgeschützte Transaktion geschlossen wird. Wir empfehlen, langlebige Transaktionen proaktiv zu überwachen und zu verwalten. Weitere Informationen finden Sie unter [Die Datenbank läuft seit langem inaktiv in Transaktionsverbindung](PostgreSQL.Tuning_proactive_insights.md#proactive-insights.idle-txn). Ändern Sie Ihre Anwendung, wenn möglich, um die Verwendung von Transaktionen mit langer Laufzeit zu vermeiden oder zu minimieren.
### Langfristige Aktionen
Untersuchen Sie Ihren Workload, um die Ursache für den Multixact-Überlauf zu ermitteln. Sie müssen das Problem beheben, um Ihren Workload zu skalieren und Warteereignisse zu reduzieren.
+ Sie müssen die DDL (Datendefinitionssprache) analysieren, die zum Erstellen Ihrer Tabellen verwendet wurde. Stellen Sie sicher, dass die Tabellenstrukturen und Indizes optimal gestaltet sind.
+ Wenn die betroffenen Tabellen Fremdschlüssel enthalten, ermitteln Sie, ob sie benötigt werden oder ob es eine andere Möglichkeit gibt, die referenzielle Integrität durchzusetzen.
+ Wenn eine Tabelle große, ungenutzte Indizes enthält, kann das dazu führen, dass der Selbstbereinigungsvorgang nicht zu Ihrem Workload passt und die Ausführung möglicherweise blockiert. Um dies zu vermeiden, suchen Sie nach ungenutzten Indizes und entfernen Sie diese vollständig. Weitere Informationen finden Sie unter [Verwalten der automatischen Bereinigung mit großen Indizes](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html).
+ Reduzieren Sie die Verwendung von Savepoints in Ihren Transaktionen.
# LWLock:pg\$1stat\$1statements
Das LWLock Warteereignis:PG\$1STAT\$1STATEMENTS tritt ein, wenn die Erweiterung die Hashtabelle, die SQL-Anweisungen verfolgt, exklusiv sperrt. `pg_stat_statements` Dies passiert in folgenden Szenarien:
+ Wenn die Anzahl der nachverfolgten Anweisungen den konfigurierten `pg_stat_statements.max`-Parameterwert erreicht und Platz für weitere Einträge geschaffen werden muss, sortiert die Erweiterung die Anzahl der Aufrufe, entfernt die 5 % der am wenigsten ausgeführten Anweisungen und füllt den Hash mit den verbleibenden Einträgen neu auf.
+ Wenn `pg_stat_statements` eine `garbage collection`-Operation für die `pgss_query_texts.stat`-Datei auf der Festplatte durchführt und die Datei neu schreibt
**Topics**
+ [Unterstützte Engine-Versionen](#apg-rpg-lwlockpgstat.supported)
+ [Kontext](#apg-rpg-lwlockpgstat.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-rpg-lwlockpgstat.causes)
+ [Aktionen](#apg-rpg-lwlockpgstat.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
## Kontext
**Grundlagen der pg\$1stat\$1statements-Erweiterung** – Die pg\$1stat\$1statements-Erweiterung verfolgt Statistiken zur Ausführung von SQL-Anweisungen in einer Hash-Tabelle nach. Die Erweiterung verfolgt SQL-Anweisungen bis zu dem durch den `pg_stat_statements.max`-Parameter definierten Grenzwert nach. Dieser Parameter bestimmt die maximale Anzahl von Anweisungen, die nachverfolgt werden können, was der maximalen Anzahl von Zeilen in der pg\$1stat\$1statements-Ansicht entspricht.
**Persistenz von Anweisungsstatistiken** – Die Erweiterung behält die Anweisungsstatistiken über Instance-Neustarts hinweg bei, indem sie Folgendes durchführt:
+ Schreiben von Daten in eine Datei mit dem Namen pg\$1stat\$1statements.stat
+ Steuern des Persistenzverhaltens mit dem pg\$1stat\$1statements.save-Parameter
Wenn pg\$1stat\$1statements.save auf Folgendes gesetzt ist:
+ on (Standard): Statistiken werden beim Herunterfahren gespeichert und beim Serverstart neu geladen
+ off: Statistiken werden weder beim Herunterfahren gespeichert noch beim Serverstart neu geladen
**Abfragetextspeicher** – Die Erweiterung speichert den Text nachverfolgter Abfragen in einer Datei mit dem Namen `pgss_query_texts.stat`. Diese Datei kann auf das Doppelte der durchschnittlichen Größe aller nachverfolgten SQL-Anweisungen anwachsen, ehe eine Garbage Collection erfolgt. Die Erweiterung erfordert eine exklusive Hash-Tabellen-Sperre während der Bereinigungsvorgänge und beim Neuschreiben der `pgss_query_texts.stat`-Datei.
**Prozess der Freigabe von Anweisungen** – Wenn die Anzahl der nachverfolgten Anweisungen den `pg_stat_statements.max`-Grenzwert erreicht und neue Anweisungen nachverfolgt werden müssen, führt die Erweiterung Folgendes durch:
+ Erhält eine exklusive Sperre (LWLock:pg\$1stat\$1statements) für die Hashtabelle.
+ Sie lädt vorhandene Daten in den lokalen Speicher.
+ Sie führt eine Schnellsortierung auf der Grundlage der Anzahl der Aufrufe durch.
+ Sie entfernt die am wenigsten aufgerufenen Anweisungen (unterste 5 %).
+ Sie füllt die Hash-Tabelle mit den verbleibenden Einträgen neu auf.
**Überwachung der Anweisungsfreigabe** – In PostgreSQL 14 und höher können Sie die Freigabe von Anweisungen mit der pg\$1stat\$1statements\$1info-Ansicht überwachen. Diese Ansicht enthält eine Freigabe-Spalte, in der angezeigt wird, wie oft Anweisungen freigegeben wurden, um Platz für neue Anweisungen zu schaffen.
Wenn die Freigabe von Anweisungen häufig erfolgt, führt dies zu einer häufigeren Garbage Collection bei der `pgss_query_texts.stat`-Datei auf der Festplatte.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Zu den typischen Ursachen für eine Zunahme bei den `LWLock:pg_stat_statements`-Wartezeiten gehören:
+ eine Zunahme bei der Anzahl eindeutiger Abfragen, die von der Anwendung verwendet werden
+ ein `pg_stat_statements.max`-Parameterwert, der im Vergleich zur Anzahl der verwendeten eindeutigen Abfragen klein ist
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. Sie können `LWLock:pg_stat_statements`-Ereignisse identifizieren, indem Sie Erkenntnisse zur Amazon-RDS-Leistung verwenden oder die `pg_stat_activity`-Ansicht abfragen.
Passen Sie die folgenden `pg_stat_statements` Parameter an, um das Tracking-Verhalten zu steuern und die Warteereignisse von pg\$1stat\$1-Anweisungen zu reduzieren. LWLock
**Topics**
+ [Deaktivieren des pg\$1stat\$1statements.track-Parameters](#apg-rpg-lwlockpgstat.actions.disabletrack)
+ [Erhöhen des pg\$1stat\$1statements.max-Parameters](#apg-rpg-lwlockpgstat.actions.increasemax)
+ [Deaktivieren des pg\$1stat\$1statements.track\$1utility-Parameters](#apg-rpg-lwlockpgstat.actions.disableutility)
### Deaktivieren des pg\$1stat\$1statements.track-Parameters
Wenn sich das LWLock Warteereignis:pg\$1stat\$1statements negativ auf die Datenbankleistung auswirkt und eine schnelle Lösung erforderlich ist, bevor die Ansicht weiter analysiert wird, um die Ursache `pg_stat_statements` zu ermitteln, kann der Parameter deaktiviert werden, indem er auf gesetzt wird. `pg_stat_statements.track` `none` Dadurch wird die Erfassung von Anweisungsstatistiken deaktiviert.
### Erhöhen des pg\$1stat\$1statements.max-Parameters
Erhöhen Sie den Wert des `pg_stat_statements.max`-Parameters, um die Freigabe zu reduzieren und die Garbage Collection für die `pgss_query_texts.stat`-Datei auf der Festplatte zu minimeren. Der Standardwert ist `5,000`.
**Anmerkung**
Der `pg_stat_statements.max`-Parameter ist statisch. Sie müssen Ihre DB-Instance neu starten, um Änderungen an diesem Parameter zu übernehmen.
### Deaktivieren des pg\$1stat\$1statements.track\$1utility-Parameters
Sie können die pg\$1stat\$1statements-Ansicht analysieren, um festzustellen, welche Dienstprogrammbefehle die meisten Ressourcen verbrauchen, die von `pg_stat_statements` nachverfolgt werden.
Der `pg_stat_statements.track_utility`-Parameter steuert, ob das Modul Dienstprogrammbefehle nachverfolgt, zu denen alle Befehle außer SELECT, INSERT, UPDATE, DELETE und MERGE gehören. Dieser Parameter ist standardmäßig auf `on` festgelegt.
Wenn Ihre Anwendung beispielsweise viele Savepoint-Abfragen verwendet, die von Natur aus eindeutig sind, kann dies die Freigabe von Anweisungen erhöhen. Als Abhilfemaßnahme können Sie den `pg_stat_statements.track_utility`-Parameter deaktivieren, sodass Savepoint-Abfragen nicht mehr von `pg_stat_statements` nachverfolgt werden.
**Anmerkung**
Der `pg_stat_statements.track_utility`-Parameter ist ein dynamischer Parameter. Sie können dessen Wert ändern, ohne Ihre Datenbank-Instance neu starten zu müssen.
**Example Beispiel für eindeutige Savepoint-Abfragen in pg\$1stat\$1statements**
```
query | queryid
-------------------------------------------------+---------------------
SAVEPOINT JDBC_SAVEPOINT_495701 | -7249565344517699703
SAVEPOINT JDBC_SAVEPOINT_1320 | -1572997038849006629
SAVEPOINT JDBC_SAVEPOINT_26739 | 54791337410474486
SAVEPOINT JDBC_SAVEPOINT_1294466 | 8170064357463507593
ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016 | -33608214779996400
SAVEPOINT JDBC_SAVEPOINT_14185 | -2175035613806809562
SAVEPOINT JDBC_SAVEPOINT_45837 | -6201592986750645383
SAVEPOINT JDBC_SAVEPOINT_1324 | 6388797791882029332
```
PostgreSQL 17 führt mehrere Verbesserungen für die Nachverfolgung von Dienstprogrammbefehlen ein:
+ Savepoint-Namen werden jetzt als Konstanten angezeigt.
+ Die globale Transaktion IDs (GIDs) von zweiphasigen Commit-Befehlen wird jetzt als Konstanten angezeigt.
+ Die Namen von DEALLOCATE-Anweisungen werden als Konstanten angezeigt.
+ CALL-Parameter werden jetzt als Konstanten angezeigt.
# Timeout:PgSleep
Das `Timeout:PgSleep`-Ereignis tritt ein, wenn ein Serverprozess die `pg_sleep`-Funktion aufgerufen hat und auf das Ablaufen des Sleep-Timeouts wartet.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-waits.timeoutpgsleep.context.supported)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-waits.timeoutpgsleep.causes)
+ [Aktionen](#apg-waits.timeoutpgsleep.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Dieses Wait-Ereignis tritt auf, wenn eine Anwendung, eine gespeicherte Funktion oder ein Benutzer eine SQL-Anweisung ausgibt, die eine der folgenden Funktionen aufruft:
+ `pg_sleep`
+ `pg_sleep_for`
+ `pg_sleep_until`
Die vorhergehenden Funktionen verzögern die Ausführung, bis die angegebene Anzahl von Sekunden verstrichen ist. Beispielsweise pausiert `SELECT pg_sleep(1)` für 1 Sekunde. Weitere Informationen finden Sie unter [Ausführung verzögern](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-DELAY) in der PostgreSQL-Dokumentation.
## Aktionen
Identifizieren Sie die Anweisung, die die `pg_sleep`-Funktion ausgeführt hat. Überprüfen Sie, ob die Verwendung der Funktion angemessen ist.