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 Ereignisse LWLock:MultiXactMemberBufferLWLock:MultiXactOffsetBuffer,LWLock:MultiXactMemberSLRU, und LWLock:MultiXactOffsetSLRU wait zeigen an, dass eine Sitzung darauf wartet, eine Liste von Transaktionen abzurufen, die dieselbe Zeile in einer bestimmten Tabelle ändern.

Unterstützte Engine-Versionen

Diese Informationen zum Warteereignis werden für alle Versionen von Aurora Postgre SQL unterstützt.

Kontext

Ein Multixact ist eine Datenstruktur, die eine Liste von Transaktionen IDs (XIDs) speichert, die dieselbe Tabellenzeile ändern. Wenn eine einzelne Transaktion auf eine Zeile in einer Tabelle verweist, wird die Transaktions-ID in der Kopfzeile der Tabelle gespeichert. Wenn mehrere Transaktionen auf dieselbe Zeile in einer Tabelle verweisen, IDs wird die Liste der Transaktionen 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

Es gibt drei häufige Ursachen für die Verwendung von Multixact:

Wenn eine bestimmte Zeile in einem Vorgang mit mehreren Transaktionen enthalten ist, muss für die Verarbeitung der Zeile die Transaktion aus den Auflistungen abgerufen werden. IDs multixact Wenn durch Lookups der Multixact nicht aus dem Speichercache abgerufen werden kann, muss die Datenstruktur aus der Aurora-Speicherschicht gelesen werden. Diese I/O 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 Wartezeiten sofort zu reduzieren. Andere erfordern jedoch möglicherweise Untersuchungen und Korrekturen, um Ihre Arbeitslast zu skalieren.

Führen Sie mit diesem Wait-Event das Vakuumfrosten von Tischen durch

Wenn dieses Warteereignis plötzlich stark ansteigt und sich auf Ihre Produktionsumgebung auswirkt, können Sie eine der folgenden temporären Methoden verwenden, um die Anzahl der Ereignisse zu reduzieren.

Erhöhen Sie mit diesem Warteereignis die Häufigkeit des automatischen Absaugens von Tischen

Nach dem Scannen aller Tabellen in allen Datenbanken VACUUM werden die Multixacts irgendwann entfernt und ihre ältesten Multixact-Werte werden erweitert. Weitere Informationen finden Sie unter Multixacts und Wraparound. Um die EreignisseLWLock: MultiXact wait so gering wie möglich zu halten, müssen Sie sie so oft VACUUM wie nötig ausführen. Stellen Sie dazu sicher, dass der VACUUM in Ihrem Aurora SQL Postgre-DB-Cluster optimal konfiguriert ist.

Wenn das Problem mit dem Warteereignis durch die Verwendung VACUUM FREEZE auf der betroffenen Tabelle oder Tabellenpartition behoben wird, empfehlen wir, einen Scheduler zu verwendenpg_cron, um das Autovacuum durchzuführen, VACUUM anstatt es auf Instance-Ebene anzupassen.

Damit das Autovakuieren häufiger erfolgt, können Sie den Wert des Speicherparameters autovacuum_multixact_freeze_max_age in der betroffenen Tabelle reduzieren. Weitere Informationen finden Sie unter autovacuum_multixact_freeze_max_age.

Erhöhen Sie die 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 Clusterebene 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 am besten entsprechen. Sie müssen die Writer-Instanz neu starten, damit die Parameteränderungen wirksam werden.

Die Parameter werden in Form von Multixact-Cache-Einträgen ausgedrückt. Jeder Cache-Eintrag belegt Speicherplatz8 KB. Um den gesamten reservierten Speicher zu berechnen, multiplizieren Sie jeden Parameterwert mit8 KB. Wenn Sie beispielsweise einen Parameter auf 128 setzen, wäre der gesamte reservierte Speicher128 * 8 KB = 1 MB.

Reduzieren Sie lang andauernde Transaktionen

Eine lang andauernde Transaktion führt dazu, dass das Vakuum seine Informationen so lange aufbewahrt, bis die Transaktion festgeschrieben 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. Versuchen Sie, Ihre Anwendung so zu modifizieren, dass Sie lange laufende Transaktionen vermeiden oder minimieren.

Langfristige Maßnahmen

Untersuchen Sie Ihren Workload, um die Ursache für den Multixact-Spillover zu ermitteln. Sie müssen das Problem beheben, um Ihre Arbeitslast zu skalieren und Wartezeiten zu reduzieren.