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:lock\$1manager Dieses Ereignis tritt ein, wenn die Aurora PostgreSQL-Engine den Speicherbereich der gemeinsam genutzten Sperre verwaltet, um eine Sperre zuzuweisen, zu überprüfen und aufzuheben, wenn eine Fast-Path-Sperre nicht möglich ist. **Topics** + [Unterstützte Engine-Versionen](#apg-waits.lw-lock-manager.context.supported) + [Kontext](#apg-waits.lw-lock-manager.context) + [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-waits.lw-lock-manager.causes) + [Aktionen](#apg-waits.lw-lock-manager.actions) ## Unterstützte Engine-Versionen Diese Warteereignisinformationen sind für Aurora PostgreSQL Version 9.6 und höher relevant. ## Kontext Wenn Sie eine SQL-Anweisung ausgeben, zeichnet Aurora PostgreSQL Sperren auf, um die Struktur, Daten und Integrität Ihrer Datenbank während gleichzeitiger Vorgänge zu schützen. Der Motor kann dieses Ziel mit einer schnellen Pfadsperre oder einer nicht schnellen Pfadsperre erreichen. Eine Pfadsperre, die nicht schnell ist, ist teurer und erzeugt mehr Overhead als eine schnelle Pfadsperre. ### Schnelle Pfadsperre Um den Overhead von Sperren zu reduzieren, die häufig genommen und freigegeben werden, aber selten in Konflikt geraten, können Backend-Prozesse eine schnelle Pfadsperrung verwenden. Die Datenbank verwendet diesen Mechanismus für Sperren, die die folgenden Kriterien erfüllen: + Sie verwenden die STANDARD–Sperrmethode. + Sie stellen eine Sperre für eine Datenbankbeziehung statt einer gemeinsamen Beziehung dar. + Sie sind schwache Sperren, die wahrscheinlich nicht in Konflikt stehen. + Die Engine kann schnell überprüfen, dass keine widersprüchlichen Sperren existieren können. Die Engine kann keine schnelle Pfadsperre verwenden, wenn eine der folgenden Bedingungen erfüllt ist: + Die Sperre erfüllt nicht die vorhergehenden Kriterien. + Für den Backend-Prozess sind keine Slots mehr verfügbar. Weitere Informationen zum Sperren von Fast Path finden Sie unter [Fast Path](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76) in der README-Datei des PostgreSQL-Sperrmanagers und unter [pg-locks](https://www.postgresql.org/docs/15/view-pg-locks.html) in der PostgreSQL-Dokumentation. ### Beispiel für ein Skalierungsproblem für den Sperrmanager In diesem Beispiel speichert eine Tabelle mit dem Namen `purchases` Daten aus fünf Jahren, aufgeteilt nach Tagen. Jede Partition hat zwei Indizes. Die folgende Abfolge von Ereignissen tritt auf: 1. Sie fragen Daten für viele Tage ab, wodurch die Datenbank viele Partitionen lesen muss. 1. Die Datenbank erstellt einen Sperreintrag für jede Partition. Wenn Partitionsindizes Teil des Optimizer-Zugriffspfads sind, erstellt die Datenbank auch für sie einen Sperreintrag. 1. Wenn die Anzahl der angeforderten Sperreneinträge für denselben Backend-Prozess höher als 16 ist, was dem Wert von `FP_LOCK_SLOTS_PER_BACKEND` entspricht, verwendet der Sperrenmanager die Sperrmethode ohne Fast Path. Moderne Anwendungen haben möglicherweise Hunderte von Sitzungen. Wenn gleichzeitige Sitzungen das übergeordnete Element ohne ordnungsgemäßen Schnitt von Partitionen abfragen, erstellt die Datenbank möglicherweise Hunderte oder sogar Tausende von nicht schnellen Pfadsperren. Wenn diese Parallelität höher als die Anzahl von v istCPUs, tritt normalerweise das Wait-Ereignis auf`LWLock:lock_manager`. **Anmerkung** Das Wait-Ereignis `LWLock:lock_manager` hat nichts mit der Anzahl der Partitionen oder Indizes in einem Datenbankschema zu tun. Stattdessen hängt es mit der Anzahl der nicht schnellen Pfadsperren zusammen, die die Datenbank steuern muss. ## Wahrscheinliche Ursachen für erhöhte Wartezeiten Wenn das `LWLock:lock_manager` häufiger als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die wahrscheinlichsten Ursachen für plötzliche Spitzen wie folgt: + Gleichzeitige aktive Sitzungen führen Abfragen aus, die keine schnellen Pfadsperren verwenden. Diese Sitzungen überschreiten auch die maximale vCPU. + Eine große Anzahl gleichzeitiger aktiver Sitzungen greift auf eine stark partitionierte Tabelle zu. Jede Partition hat mehrere Indizes. + Die Datenbank erlebt einen Verbindungssturm. Standardmäßig erzeugen einige Anwendungen und Connection Pool-Software mehr Verbindungen, wenn die Datenbank langsam ist. Diese Praxis verschlimmert das Problem. Optimieren Sie Ihre Connection Pool-Software so, dass keine Verbindungsstürme auftreten. + Eine große Anzahl von Sitzungen fragt eine übergeordnete Tabelle ab, ohne Partitionen zu beschneiden. + Eine Datendefinitionssprache (DDL), Datenmanipulationssprache (DML) oder ein Wartungsbefehl sperrt ausschließlich eine Beleg-Beziehung oder Tupel, auf die häufig zugegriffen oder geändert werden. ## Aktionen Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. **Topics** + [Verwenden Sie das Beschneiden von Partitionen](#apg-waits.lw-lock-manager.actions.pruning) + [Entfernen unnötiger Indizes](#apg-waits.lw-lock-manager.actions.indexes) + [Optimieren Sie Ihre Abfragen für schnelles Pfadsperren](#apg-waits.lw-lock-manager.actions.tuning) + [Tune auf andere Warteereignisse](#apg-waits.lw-lock-manager.actions.other-waits) + [Reduzieren von Hardware-Engpässen](#apg-waits.lw-lock-manager.actions.hw-bottlenecks) + [Verwenden eines Verbindungs-Poolers](#apg-waits.lw-lock-manager.actions.pooler) + [Aktualisieren Sie Ihre Aurora PostgreSQL Version](#apg-waits.lw-lock-manager.actions.pg-version) ### Verwenden Sie das Beschneiden von Partitionen Die *Partitionsbereinigung* ist eine Strategie zur Abfrageoptimierung, die nicht benötigte Partitionen von Tabellenscans ausschließt und dadurch die Leistung verbessert. Das Beschneiden der Partition ist standardmäßig aktiviert. Wenn es ausgeschaltet ist, schalten Sie es wie folgt ein. ``` SET enable_partition_pruning = on; ``` Abfragen können die Partitionsbereinigung nutzen, wenn ihre `WHERE`-Klausel die für die Partitionierung verwendete Spalte enthält. Weitere Informationen finden Sie unter [Partitionsbereinigung](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING) in der PostgreSQL-Dokumentation. ### Entfernen unnötiger Indizes Ihre Datenbank enthält möglicherweise nicht verwendete oder selten verwendete Indizes. Wenn ja, erwägen Sie, sie zu löschen. Führen Sie eine der folgenden Aufgaben aus: + Erfahren Sie, wie Sie unnötige Indizes finden, indem Sie [Ungenutzte Indizes](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes) im PostgreSQL-Wiki lesen. + Führen Sie PG Collector aus. Dieses SQL-Skript sammelt Datenbankinformationen und präsentiert sie in einem konsolidierten HTML-Bericht. Überprüfen Sie den Abschnitt „Unbenutzte Indizes“. Weitere Informationen finden Sie unter [pg-collector im Labs-Repository](https://github.com/awslabs/pg-collector). AWS GitHub ### Optimieren Sie Ihre Abfragen für schnelles Pfadsperren Um herauszufinden, ob Ihre Abfragen Fast Path Locking verwenden, fragen Sie die `fastpath`-Spalte in der `pg_locks`-Tabelle ab. Wenn Ihre Abfragen keine schnelle Pfadsperre verwenden, versuchen Sie, die Anzahl der Beziehungen pro Abfrage auf weniger als 16 zu reduzieren. ### Tune auf andere Warteereignisse Wenn `LWLock:lock_manager` in der Liste der Top-Waits an erster oder zweiter Stelle steht, überprüfen Sie, ob die folgenden Wait-Ereignisse auch in der Liste erscheinen: + `Lock:Relation` + `Lock:transactionid` + `Lock:tuple` Wenn die vorhergehenden Ereignisse in der Liste hoch erscheinen, sollten Sie zuerst diese Warteereignisse optimieren. Diese Ereignisse können ein Treiber für `LWLock:lock_manager`. ### Reduzieren von Hardware-Engpässen Möglicherweise haben Sie einen Hardware-Engpass wie CPU-Hunger oder maximale Auslastung Ihrer Amazon EBS-Bandbreite. Ziehen Sie in diesen Fällen die Verringerung der Hardware-Engpässe in Betracht. Berücksichtigen Sie die folgenden Aktionen: + Skalieren Sie Ihre Instance-Klasse hoch. + Optimieren Sie Abfragen, die große Mengen an CPU und Speicher verbrauchen. + Ändern Sie Ihre Anwendungslogik. + Archiviere deine Daten. Weitere Informationen zu CPU, Arbeitsspeicher und EBS-Netzwerkbandbreite finden Sie unter [Amazon-RDS-Instance-Typen](https://aws.amazon.com/rds/instance-types/). ### Verwenden eines Verbindungs-Poolers Wenn Ihre Gesamtzahl aktiver Verbindungen die maximale vCPU überschreitet, benötigen mehr Betriebssystemprozesse CPU, als Ihr Instance-Typ unterstützen kann. Ziehen Sie in diesem Fall die Verwendung oder Abstimmung eines Verbindungspool in Betracht. Weitere Informationen über das v CPUs für Ihren Instance-Typ finden Sie unter [Amazon RDS-Instance-Typen](https://aws.amazon.com/rds/instance-types/). Weitere Informationen zum Verbindungspooling finden Sie in den folgenden Ressourcen: + [Amazon RDS-Proxy für Aurora](rds-proxy.md) + [pgbouncer](http://www.pgbouncer.org/usage.html) + [Verbindungspools und Datenquellen](https://www.postgresql.org/docs/7.4/jdbc-datasource.html) in der *PostgreSQL-Dokumentation* ### Aktualisieren Sie Ihre Aurora PostgreSQL Version Wenn Ihre aktuelle Version von Aurora PostgreSQL niedriger als 12 ist, aktualisieren Sie auf Version 12 oder höher. PostgreSQL Versionen 12 und 13 haben einen verbesserten Partitionsmechanismus. Weitere Informationen zu Version 12 finden Sie in den [Versionshinweisen zu PostgreSQL 12.0]( https://www.postgresql.org/docs/release/12.0/). Weitere Informationen zum Aktualisieren von Aurora PostgreSQL finden Sie unter [Aktualisierungen der Datenbank-Engine für Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md).