LWLock:BufferMapping (LWLock:buffer_mapping)

Dieses Ereignis tritt ein, wenn eine Sitzung darauf wartet, einen Datenblock einem Puffer im gemeinsam genutzten Pufferpool zuzuordnen.

Anmerkung

Dieses Ereignis trägt in RDS für PostgreSQL Version 13 und höheren Versionen den Namen LWLock:BufferMapping. In PostgreSQL Version 12 und älteren Versionen lautet die Bezeichnung dieses Ereignisses LWLock:buffer_mapping.

Unterstützte Engine-Versionen

Diese Warteereignisinformationen sind für RDS für PostgreSQL Version 9.6 und höher relevant.

Kontext

Der freigegebene Pufferpool ist ein 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.

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.

Themen

• Überwachen Sie pufferbezogene Metriken
• Bewerten Sie Ihre Indexierungsstrategie
• Reduzieren Sie die Anzahl der Puffer, die schnell zugewiesen werden müssen

Ü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:

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 Zählermetrik für Performance Insights gibt die Anzahl der Blöcke an, für die I/O in den freigegebenen 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.