LWLock:buffer_mapping - Amazon Aurora

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

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

Anmerkung

Dieses Ereignis wird in Aurora PostgreSQL Version 12 und niedriger als LWLock:buffer_mapping und in Version 13 und höher als LWLock:BufferMapping angezeigt.

Unterstützte Engine-Versionen

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

Context

Der freigegebene Pufferpool ist ein Aurora 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. Weitere Informationen finden Sie unter Freigegebene Puffer.

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 Wait-Ereignisses empfehlen wir verschiedene Aktionen.

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

BufferCacheHitRatio

Diese Amazon CloudWatch-Metrik misst den Prozentsatz der Anfragen, die vom Puffer-Cache einer DB-Instance in Ihrem DB-Cluster verarbeitet werden. Möglicherweise sehen Sie diese Metrikabnahme im Vorfeld des LWLock:buffer_mapping-Wait-Ereignisses.

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.