Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Aurora PostgreSQL-Warteereignisse
Die folgende Tabelle listet die Warteereignisse für Aurora PostgreSQL auf, die am häufigsten auf Leistungsprobleme hinweisen, und fasst die häufigsten Ursachen und Korrekturmaßnahmen zusammen. Die folgenden Warteereignisse sind eine Teilmenge der Liste in Amazon Aurora SQL Postgre-Warteereignisse.
| Warteereignis | Definition |
|---|---|
|
Dieses Ereignis tritt ein, wenn Aurora PostgreSQL darauf wartet, Daten vom Client zu empfangen. |
|
|
Dieses Ereignis tritt ein, wenn Aurora PostgreSQL darauf wartet, Daten an den Client zu schreiben. |
|
|
Dieses Ereignis tritt auf, wenn ein Thread in der CPU aktiv ist oder auf die CPU wartet. |
|
|
Diese Ereignisse treten auf, wenn Aurora PostgreSQL temporäre Dateien erstellt. |
|
|
Dieses Ereignis tritt auf, wenn eine Verbindung darauf wartet, dass ein Backend-Prozess eine erforderliche Seite aus dem Speicher liest, da die Seite nicht im gemeinsam genutzten Speicher verfügbar ist. |
|
|
Dieses Ereignis tritt ein, wenn die Datenbank darauf wartet, dass das Aurora-Storage-Subsystem den Commit einer regulären Transaktion bzw. den Commit oder Rollback einer vorbereiteten Transaktion ausführt. |
|
|
Dieses Ereignis tritt auf, wenn Aurora PostgreSQL in einer Sitzung, die Datenbank-Aktivitätsstreams verwendet, ein Aktivitätsstream-Ereignis erzeugt und dann wartet, bis dieses Ereignis dauerhaft wird |
|
|
Dieses Ereignis tritt auf, wenn eine PostgreSQL-Anwendung eine Sperre verwendet, um Aktivitäten über mehrere Sitzungen hinweg zu koordinieren. |
|
|
Dieses 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. |
|
|
Dieses Ereignis tritt ein, wenn eine Abfrage darauf wartet, eine Sperre für eine Tabelle oder Ansicht zu erhalten, die derzeit von einer anderen Transaktion gesperrt ist. |
|
Dieses Ereignis tritt ein, wenn eine Transaktion auf eine Sperre auf Zeilenebene wartet. |
|
|
Dieses Ereignis tritt ein, wenn ein Backend-Prozess darauf wartet, eine Sperre für ein Tupel zu erlangen. |
|
|
Dieses Ereignis 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. |
|
|
Dieses Ereignis tritt ein, wenn eine Sitzung darauf wartet, einen Datenblock einem Puffer im gemeinsam genutzten Pufferpool zuzuordnen. |
|
|
Dieses Ereignis tritt auf, 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. |
|
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. |
|
| Diese Art von Ereignis tritt auf, wenn Aurora PostgreSQL eine Sitzung offen hält, um mehrere Transaktionen abzuschließen, die dieselbe Zeile in einer Tabelle betreffen. Das Warteereignis gibt an, welcher Aspekt der Verarbeitung mehrerer Transaktionen das Warteereignis generiert, d. h. LWLock:MultiXactOffsetSLRU, LWLock:MultiXactOffsetBuffer, LWLock:MultiXactMemberSLRU oder LWLock:MultiXactMemberBuffer. | |
|
Dieses Ereignis tritt ein, wenn ein Serverprozess die Funktion |
