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 Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.

Kontext

Ein Multixact ist eine Datenstruktur, die eine Liste von Transaction 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. 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 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 entfernt VACUUM schließlich Multixacts, und ihre ältesten Multixact-Werte werden weiterverwendet. Weitere Informationen finden Sie unter Multixacts und Wraparound. Um die Ereignisse LWLock: MultiXact wait auf ein Minimum zu beschränken, müssen Sie VACUUM so oft wie nötig ausführen. Stellen Sie dazu sicher, dass das VACUUM 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 zu verwenden, z. B. um VACUUM durchzuführenpg_cron, anstatt das Autovacuum auf Instance-Ebene anzupassen.

Damit das Autovakuieren häufiger stattfindet, 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 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 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.