LWLock:lock_manager - Amazon Aurora
Unterstützte Engine-VersionenKontextWahrscheinliche Ursachen für erhöhte WartezeitenAktionen

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 in der README-Datei des PostgreSQL-Sperrmanagers und unter pg-locks 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.

  2. 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.

  3. 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 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.

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 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 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:

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. Weitere Informationen zum Aktualisieren von Aurora PostgreSQL finden Sie unter Amazon Aurora Postgre-Aktualisierungen SQL.