LWLock:buffer_content () BufferContent

Das Ereignis LWLock:buffer_content tritt ein, wenn eine Sitzung darauf wartet, eine Datenseite im Speicher zu lesen oder zu schreiben, während eine andere Sitzung diese Seite zum Schreiben gesperrt hat. In Aurora PostgreSQL 13 und höher heißt dieses Warteereignis BufferContent.

Unterstützte Engine-Versionen

Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.

Kontext

Um Daten zu lesen oder zu manipulieren, greift PostgreSQL über Shared Memory Puffer darauf zu. Um aus dem Puffer zu lesen, erhält ein Prozess im Shared-Modus eine einfache Sperre (LWLock) für den Pufferinhalt. Um in den Puffer zu schreiben, wird diese Sperre im exklusiven Modus angezeigt. Gemeinsame Sperren ermöglichen es anderen Prozessen, gleichzeitig gemeinsame Sperren für diesen Inhalt zu erwerben. Exklusive Sperren verhindern, dass andere Prozesse irgendeine Art von Sperre erhalten.

Das Ereignis LWLock:buffer_content (BufferContent) weist darauf hin, dass mehrere Prozesse versuchen, Lightweight-Locks (LWLocks) für den Inhalt eines bestimmten Puffers zu aktivieren.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Wenn das LWLock:buffer_content(BufferContent)-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:

Die gleichzeitigen Aktualisierungen der gleichen Daten wurden erhöht

Es kann zu einer Zunahme der Anzahl gleichzeitiger Sitzungen mit Abfragen kommen, die denselben Pufferinhalt aktualisieren. Diese Behauptung kann bei Tabellen mit vielen Indizes ausgeprägter sein.

Workload-Daten befinden sich nicht im Speicher

Wenn sich Daten, die die aktive Workload verarbeitet, nicht im Speicher befinden, können diese Warteereignisse zunehmen. Dieser Effekt ist darauf zurückzuführen, dass Prozesse, die Sperren enthalten, diese länger behalten können, während sie I/O Festplattenoperationen ausführen.

Übermäßiger Einsatz von Fremdschlüsselbeschränkungen

Fremdschlüsseleinschränkungen können die Zeit erhöhen, die ein Prozess an einer Pufferinhaltssperre hält. Dieser Effekt liegt daran, dass Lesevorgänge eine gemeinsame Pufferinhaltssperre für den referenzierten Schlüssel erfordern, während dieser Schlüssel aktualisiert wird.

Aktionen

Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. Sie können LWLock:buffer_content(BufferContent)-Ereignisse identifizieren, indem Sie Amazon RDS Performance Insights verwenden oder die Ansicht pg_stat_activity abfragen.

Themen

• Verbessern Sie die Effizienz im Speicher

• Reduzieren Sie die Verwendung von Fremdschlüsselbeschränkungen

• Entferne nicht verwendete Indizes

• Doppelte Indizes entfernen

• Ungültige Indizes löschen oder NEU INDIZIEREN

• Verwenden Sie Teilindizes

• Entfernen Sie die Aufblähung von Tabellen und Indizes

Verbessern Sie die Effizienz im Speicher

Um die Wahrscheinlichkeit zu erhöhen, dass sich aktive Workload-Daten im Speicher befinden, partitionieren Sie Tabellen oder skalieren Sie Ihre Instance-Klasse hoch. Weitere Informationen zu DB-Instance-Klassen finden Sie unter Amazon Aurora Aurora-DB-Instance-Klassen.

Überwachen Sie die BufferCacheHitRatio Metrik, die den Prozentsatz der Anfragen misst, die vom Puffercache einer DB-Instance in Ihrem DB-Cluster bedient werden. Diese Metrik gibt Aufschluss über die Datenmenge, die aus dem Speicher bereitgestellt wird. Eine hohe Trefferquote bedeutet, dass Ihre DB-Instance über ausreichend Arbeitsspeicher für Ihren Arbeitsdatensatz verfügt, während eine niedrige Trefferquote darauf hindeutet, dass Ihre Abfragen häufig auf Daten aus dem Speicher zugreifen.

Die Cache-Lesetreffer pro Tabelle und die Cache-Lesetreffer pro Index im Abschnitt Speichereinstellungen des PG Collector-Berichts können Aufschluss über die Cache-Trefferquote von Tabellen und Indizes geben.

Reduzieren Sie die Verwendung von Fremdschlüsselbeschränkungen

Untersuchen Sie Workloads, bei denen eine hohe Anzahl von LWLock:buffer_content(BufferContent)-Wait-Ereignissen auf die Verwendung von Fremdschlüsseleinschränkungen auftritt. Entfernen Sie unnötige Fremdschlüsselbeschränkungen.

Entferne nicht verwendete Indizes

Identifizieren Sie bei Workloads mit einer hohen Anzahl von LWLock:buffer_content(BufferContent)-Wait-Ereignissen nicht verwendete Indizes und entfernen Sie sie.

Der Abschnitt „Unbenutzte Indizes“ des PG Collector-Berichts kann Einblicke in die ungenutzten Indizes in der Datenbank geben.

Doppelte Indizes entfernen

Identifizieren Sie doppelte Indizes und entfernen Sie sie.

Der Abschnitt über doppelte Indizes des PG Collector-Berichts kann Einblicke in die doppelten Indizes in der Datenbank geben.

Ungültige Indizes löschen oder NEU INDIZIEREN

Ungültige Indizes treten normalerweise auf, wenn Sie CREATE INDEX CONCURRENTLY oder verwenden REINDEX CONCURRENTLY und der Befehl fehlschlägt oder abgebrochen wird.

Ungültige Indizes können nicht für Abfragen verwendet werden, obwohl sie trotzdem aktualisiert werden und Speicherplatz beanspruchen.

Der Abschnitt Ungültige Indizes des PG Collector-Berichts kann Einblicke in die ungültigen Indizes in der Datenbank geben.

Verwenden Sie Teilindizes

Teilindizes können genutzt werden, um die Abfrageleistung zu verbessern und die Indexgröße zu reduzieren. Ein Teilindex ist ein Index, der auf einer Teilmenge einer Tabelle basiert, wobei die Teilmenge durch einen bedingten Ausdruck definiert ist. Wie in der Dokumentation zum Teilindex beschrieben, können Teilindizes den Aufwand für die Verwaltung von Indizes reduzieren, da PostgreSQL den Index nicht in allen Fällen aktualisieren muss.

Entfernen Sie die Aufblähung von Tabellen und Indizes

Übermäßiges Aufblähen von Tabellen und Indizes kann sich negativ auf die Datenbankleistung auswirken. Aufgeblähte Tabellen und Indizes erhöhen die Größe des aktiven Arbeitssatzes, wodurch die Effizienz im Arbeitsspeicher beeinträchtigt wird. Darüber hinaus erhöht die Aufblähung die Speicherkosten und verlangsamt die Ausführung von Abfragen. Informationen zur Diagnose von Blähungen finden Sie in der. Diagnostizieren einer Überlastung von Tabellen und Indizes Darüber hinaus bietet der Abschnitt Fragmentierung (Bloat) des PG Collector-Berichts Einblicke in die Fülle von Tabellen und Indizes.

Um das Aufblähen von Tabellen und Indizes zu beheben, gibt es einige Optionen:

VACUUM FULL

VACUUM FULLerstellt eine neue Kopie der Tabelle, wobei nur die aktiven Tupel kopiert werden, und ersetzt dann die alte Tabelle durch die neue, wobei eine Sperre erhalten bleibt. ACCESS EXCLUSIVE Dadurch wird jegliches Lesen oder Schreiben in die Tabelle verhindert, was zu einem Ausfall führen kann. Außerdem VACUUM FULL dauert es länger, wenn die Tabelle groß ist.

pg_repack

Das pg_repack ist hilfreich in Situationen, in denen VACUUM FULL dies möglicherweise nicht geeignet ist. Es erstellt eine neue Tabelle, die die Daten der aufgeblähten Tabelle enthält, verfolgt die Änderungen gegenüber der Originaltabelle und ersetzt dann die Originaltabelle durch die neue. Es sperrt die Originaltabelle nicht für Lese- oder Schreibvorgänge, während die neue Tabelle erstellt wird. Weitere Informationen zur Verwendung pg_repack finden Sie unter Bloat mit pg_repack und pg_repack entfernen.

REINDEX

Der REINDEX Befehl kann genutzt werden, um das Aufblähen des Indexes zu beheben. REINDEXschreibt eine neue Version des Indexes ohne die toten Seiten oder die leeren oder fast leeren Seiten, wodurch der Platzbedarf des Indexes reduziert wird. Ausführliche Informationen zu dem REINDEXBefehl finden Sie in der REINDEX-Dokumentation.

Nach dem Entfernen von Blähungen aus Tabellen und Indizes kann es notwendig sein, die Autovakuum-Frequenz in diesen Tabellen zu erhöhen. Durch die Implementierung aggressiver Autovakuumeinstellungen auf Tabellenebene kann verhindert werden, dass es in future zu Blähungen kommt. Weitere Informationen finden Sie in der Dokumentation unter. Vacuuming and analyzing tables automatically