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_manager
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.
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
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:
-
Sie fragen Daten für viele Tage ab, wodurch die Datenbank viele Partitionen lesen muss.
-
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.
-
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_BACKENDentspricht, 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 der vCPUs ist, wird normalerweise das LWLock:lock_manager-Warteereignis angezeigt.
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.
Themen
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
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
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 AWS-Labs GitHub-Repository.
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
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 zu den vCPUs für Ihren Instance-Typ finden Sie unter Amazon RDS-Instance-Typen
Weitere Informationen zum Verbindungspooling finden Sie in den folgenden Ressourcen:
-
Verbindungspools und Datenquellen
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
