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\$1content () 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`.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-waits.lockbuffercontent.context.supported)
+ [Kontext](#apg-waits.lockbuffercontent.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-waits.lockbuffercontent.causes)
+ [Aktionen](#apg-waits.lockbuffercontent.actions)
## 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, einfache Sperren (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.
**Topics**
+ [Verbessern Sie die Effizienz im Speicher](#apg-waits.lockbuffercontent.actions.in-memory)
+ [Reduzieren Sie die Verwendung von Fremdschlüsselbeschränkungen](#apg-waits.lockbuffercontent.actions.foreignkey)
+ [Entferne nicht verwendete Indizes](#apg-waits.lockbuffercontent.actions.indexes)
+ [Entfernen von doppelten Indizes](#apg-waits.lockbuffercontent.actions.duplicate-indexes)
+ [Löschen oder NEU INDIZIEREN von ungültigen Indizes](#apg-waits.lockbuffercontent.actions.invalid-indexes)
+ [Verwenden von partiellen Indizes](#apg-waits.lockbuffercontent.actions.partial-indexes)
+ [Entfernen von überflüssigen Daten aus Tabellen und Indizes (Bloat)](#apg-waits.lockbuffercontent.actions.bloat)
### 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](Concepts.DBInstanceClass.md).
Überwachen Sie die `BufferCacheHitRatio`-Metrik. Diese misst den Prozentsatz der Anfragen, die vom Puffer-Cache einer DB-Instance in Ihrem DB-Cluster verarbeitet werden. Diese Metrik gibt Aufschluss über die Datenmenge, die vom Speicher bereitgestellt wird. Eine hohe Trefferrate bedeutet, dass Ihre DB-Instance über ausreichend Speicherplatz für Ihren Arbeitsdatensatz verfügt, während eine niedrige Trefferrate 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 zu den Speichereinstellungen des [PG-Collector](https://github.com/awslabs/pg-collector)-Berichts können Aufschluss über die Cache-Trefferrate 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 zu nicht genutzten Indizes im [PG-Collector](https://github.com/awslabs/pg-collector)-Bericht kann Aufschluss über die nicht genutzten Indizes in der Datenbank geben.
### Entfernen von doppelten Indizes
Identifizieren Sie doppelte Indizes und entfernen Sie sie.
Der Abschnitt zu doppelten Indizes im [PG-Collector](https://github.com/awslabs/pg-collector)-Bericht kann Aufschluss über die doppelten Indizes in der Datenbank geben.
### Löschen oder NEU INDIZIEREN von ungültigen Indizes
Ungültige Indizes kommen in der Regel vor, wenn `CREATE INDEX CONCURRENTLY` oder `REINDEX CONCURRENTLY` verwendet wird und der Befehl fehlschlägt oder abgebrochen wird.
Ungültige Indizes können nicht für Abfragen verwendet werden, werden aber trotzdem aktualisiert und beanspruchen Speicherplatz.
Der Abschnitt zu ungültigen Indizes im [PG-Collector](https://github.com/awslabs/pg-collector)-Bericht kann Aufschluss über ungültige Indizes in der Datenbank geben.
### Verwenden von partiellen Indizes
Partielle Indizes können verwendet werden, um die Abfrageleistung zu verbessern und die Indexgröße zu reduzieren. Ein partieller Index ist ein Index, der auf einer Teilmenge einer Tabelle basiert, wobei die Teilmenge durch einen bedingten Ausdruck definiert ist. Wie in der [partial index](https://www.postgresql.org/docs/current/indexes-partial.html)-Dokumentation beschrieben, können partielle Indizes den Aufwand für die Verwaltung von Indizes reduzieren, da PostgreSQL den Index nicht in jedem Fall aktualisieren muss.
### Entfernen von überflüssigen Daten aus Tabellen und Indizes (Bloat)
Ein übermäßiger Tabellen- und Index-Bloat kann sich negativ auf die Datenbankleistung auswirken. Tabellen und Indizes, die viel überflüssige Daten enthalten, erhöhen die Größe des aktiven Arbeitssatzes, wodurch die Effizienz im Arbeitsspeicher beeinträchtigt wird. Darüber hinaus erhöhen überflüssige Daten die Speicherkosten und verlangsamen die Ausführung von Abfragen. Informationen zur Bloat-Diagnose finden Sie unter [Diagnostizieren einer Überlastung von Tabellen und Indizes](AuroraPostgreSQL.diag-table-ind-bloat.md). Darüber hinaus gibt der Abschnitt zur Fragmentierung (Bloat) im [PG-Collector](https://github.com/awslabs/pg-collector)-Bericht Aufschluss über Tabellen und Indizes mit überflüssigen Daten.
Zur Behebung des Problems der überflüssigen Daten in Tabellen und Indizes gibt es einige Optionen:
**VACUUM FULL**
`VACUUM FULL` erstellt eine neue Kopie der Tabelle, wobei nur die aktiven Tupel kopiert werden, und ersetzt dann die alte Tabelle durch die neue, wobei eine `ACCESS EXCLUSIVE`-Sperre beibehalten wird. Dadurch wird jegliches Lesen oder Schreiben in die Tabelle verhindert, was zu einem Ausfall führen kann. Außerdem dauert `VACUUM FULL` länger, wenn die Tabelle groß ist.
**pg\$1repack**
`pg_repack` ist hilfreich in Situationen, in denen `VACUUM FULL` möglicherweise nicht geeignet ist. Es erstellt eine neue Tabelle, die die Daten der Tabelle mit den überflüssigen Daten enthält, verfolgt die Änderungen gegenüber der Originaltabelle nach und ersetzt diese Tabelle dann 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 von `pg_repack` finden Sie unter [Reduzieren von überflüssigen Daten mit pg\$1repack](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/pg-repack.html) und unter [pg\$1repack](https://reorg.github.io/pg_repack/).
**REINDEX**
Der `REINDEX`-Befehl kann genutzt werden, um das Problem eines Index-Bloat zu beheben. `REINDEX` schreibt eine neue Version des Index ohne die „toten“ oder leeren bzw. fast leeren Seiten, was den Platzverbrauch des Index reduziert. Detaillierte Informationen zum [https://www.postgresql.org/docs/current/sql-reindex.html](https://www.postgresql.org/docs/current/sql-reindex.html)-Befehl finden Sie in der REINDEX-Dokumentation.
Nach dem Entfernen der überflüssigen Daten aus Tabellen und Indizes kann es notwendig sein, die Selbstbereinigungsfrequenzen für diese Tabellen zu erhöhen. Die Implementierung von Einstellungen für eine aggressive Selbstbereinigung auf Tabellenebene kann dazu beitragen, überflüssige Daten zu vermeiden. Weitere Informationen finden Sie in der Dokumentation über [https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html).