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.

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.

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:

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.

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.

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. 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_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:

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. Ä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.