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.
Themen
Ü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 inblks_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 inblks_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. Dietup_fetched
-Metrik zeigt die Anzahl der an den Client zurückgegebenen Zeilen. Wenntup_returned
deutlich größer alstup_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.