Lock:Relation - 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.

Lock:Relation

Das Lock:Relation-Ereignis tritt ein, wenn eine Abfrage darauf wartet, eine Sperre für eine Tabelle oder Sicht (Relation) zu erhalten, die derzeit von einer anderen Transaktion gesperrt ist.

Unterstützte Engine-Versionen

Diese Informationen zum Warteereignis werden für alle Versionen von Aurora Postgre SQL unterstützt.

Kontext

Die meisten SQL Postgre-Befehle verwenden implizit Sperren, um den gleichzeitigen Zugriff auf Daten in Tabellen zu steuern. Sie können diese Sperren auch explizit mit dem LOCK-Befehl in Ihrem Anwendungscode verwenden. Viele Sperrmodi sind nicht miteinander kompatibel und können Transaktionen blockieren, wenn sie versuchen, auf dasselbe Objekt zuzugreifen. In diesem Fall SQL generiert Aurora Postgre ein Lock:Relation Ereignis. Einige gängige Beispiele sind die folgenden:

  • Exklusive Sperren wie ACCESS EXCLUSIVE können alle gleichzeitigen Zugriffe blockieren. Operationen in der Datendefinitionssprache (DDL) wieDROP TABLE, TRUNCATEVACUUM FULL, und CLUSTER erwerben implizit ACCESS EXCLUSIVE Sperren. ACCESS EXCLUSIVEist auch der Standardsperrmodus für LOCK TABLE Anweisungen, die keinen Modus explizit angeben.

  • Die Verwendung CREATE INDEX (without CONCURRENT) in einer Tabelle führt zu Konflikten mit den AnweisungenUPDATE, und DELETEINSERT, die ROW EXCLUSIVE Sperren der Datenmanipulationssprache (DML) erwerben.

Weitere Informationen zu Sperren auf Tabellenebene und widersprüchlichen Sperrmodi finden Sie unter Explizites Sperren in der Postgre-Dokumentation. SQL

Blockieren von Abfragen und Transaktionen entsperren in der Regel auf eine der folgenden Arten:

  • Blockierende Abfrage — Die Anwendung kann die Abfrage abbrechen oder der Benutzer kann den Prozess beenden. Die Engine kann die Abfrage auch aufgrund des Statement-Timeouts einer Sitzung oder eines Deadlock-Erkennungsmechanismus zum Ende zwingen.

  • Blockieren einer Transaktion – Eine Transaktion stoppt die Blockierung, wenn sie eine ROLLBACK- oder COMMIT-Anweisung ausführt. Rollbacks erfolgen auch automatisch, wenn Sitzungen von einem Client oder durch Netzwerkprobleme getrennt oder beendet werden. Sitzungen können beendet werden, wenn das Datenbank-Engine heruntergefahren wird, wenn das System keinen Arbeitsspeicher mehr hat usw.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Wenn das Lock:Relation-Ereignis häufiger als normal auftritt, kann dies auf ein Leistungsproblem hinweisen. Zu den typischen Ursachen zählen auch die Folgenden:

Gleichzeitige Sitzungen mit widersprüchlichen Tabellensperren erhöht

Es kann zu einer Zunahme der Anzahl gleichzeitiger Sitzungen mit Abfragen kommen, die dieselbe Tabelle mit widersprüchlichen Sperrmodi sperren.

Wartungsvorgänge

Zustandswartungsvorgänge wie VACUUM und ANALYZE können die Anzahl widersprüchlicher Sperren erheblich erhöhen. VACUUM FULL erhält eine ACCESS EXCLUSIVE-Sperre und ANALYZE erhält eine SHARE UPDATE EXCLUSIVE-Sperre. Beide Arten von Sperren können ein Lock:Relation-Wait-Ereignis verursachen. Wartungsvorgänge für Anwendungsdaten wie das Aktualisieren einer materialisierten Ansicht können auch blockierte Abfragen und Transaktionen erhöhen.

Sperrt bei Reader-In

Es könnte ein Konflikt zwischen den Beziehungssperren bestehen, die vom Writer und den Readern gehalten werden. Derzeit werden nur ACCESS EXCLUSIVE-Beziehungssperren auf Reader-Instances repliziert. Allerdings gerät die ACCESS EXCLUSIVE-Beziehungssperre in Konflikt mit jeder ACCESS SHARE-Beziehungssperre, die vom Reader gehalten wird. Dies kann zu einer Erhöhung der Warteereignisse für die Sperrbeziehung des Readers führen.

Aktionen

Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.

Reduzieren Sie die Auswirkungen blockierender Anweisungen SQL

Um die Auswirkungen blockierender SQL Anweisungen zu verringern, ändern Sie Ihren Anwendungscode nach Möglichkeit. Es folgen zwei gängige Techniken zum Reduzieren von Blöcken:

  • Verwenden Sie die NOWAIT Option — Einige SQL Befehle, wie z. B. SELECT LOCK AND-Anweisungen, unterstützen diese Option. Die NOWAIT-Direktive bricht die Sperre anfordernde Abfrage ab, wenn die Sperre nicht sofort erworben werden kann. Diese Technik kann dazu beitragen, zu verhindern, dass eine Blockiersitzung eine Anhäufung blockierter Sitzungen dahinter verursacht.

    Beispiel: Angenommen, Transaktion A wartet auf eine Sperre, die von Transaktion B gehalten wird. Wenn B nun eine Sperre für eine Tabelle anfordert, die durch Transaktion C gesperrt ist, könnte Transaktion A blockiert werden, bis die Transaktion C abgeschlossen ist. Wenn Transaktion B jedoch ein NOWAIT verwendet, wenn sie die Sperre für C anfordert, kann sie schnell fehlschlagen und sicherstellen, dass Transaktion A nicht unbegrenzt warten muss.

  • Verwenden SET lock_timeout — Legen Sie einen lock_timeout Wert fest, um die Zeit zu begrenzen, die eine SQL Anweisung darauf wartet, eine Relation zu sperren. Wenn die Sperre nicht innerhalb des angegebenen Timeouts erreicht wird, wird die Transaktion, die die Sperre anfordert, abgebrochen. Stellen Sie diesen Wert auf Sitzungsebene ein.

Minimieren Sie die Auswirkungen von Wartungsvorgängen

Wartungsvorgänge wie VACUUM und ANALYZE sind wichtig. Wir empfehlen, sie nicht zu deaktivieren, da Sie Lock:Relation-Warteereignisse im Zusammenhang mit diesen Wartungsvorgängen finden. Die folgenden Ansätze können die Auswirkungen dieser Vorgänge minimieren:

  • Führen Sie Wartungsvorgänge während außerhalb der Hauptverkehrszeiten manuell aus.

  • Um Lock:Relation-Wartezeiten zu reduzieren, die durch Autovacuum-Aufgaben verursacht werden, führen Sie alle erforderlichen Autovacuum-Optimierungen durch. Informationen zur Optimierung des Autovakuums finden Sie im Amazon-Benutzerhandbuch unter Arbeiten mit SQL Postgre-Autovacuum RDS bei Amazon RDS.

Auf Lesersperren überprüfen

Sie können sehen, wie gleichzeitige Sitzungen bei einem Autor und Lesern Sperren halten, die sich gegenseitig blockieren. Eine Möglichkeit dazu besteht darin, Abfragen auszuführen, die den Sperrtyp und die Beziehung zurückgeben. In der Tabelle finden Sie eine Abfolge von Abfragen zu zwei solchen gleichzeitigen Sitzungen, einer Writer-Sitzung und einer Leser-Sitzung.

Der Wiedergabevorgang wartet für die Dauer von, max_standby_streaming_delay bevor die Leserabfrage abgebrochen wird. Wie im Beispiel gezeigt, liegt das Sperr-Timeout von 100 ms deutlich unter dem standardmäßigen max_standby_streaming_delay-Wert von 30 Sekunden. Für die Sperre tritt ein Timeout auf, bevor ein Problem entsteht.

Sequenzereignis Sitzung Befehl oder Ausgabe

Legt eine Umgebungsvariable fest, die READER mit dem angegebenen Wert aufgerufen wird, und versucht, über diesen Endpunkt eine Verbindung zur DB-Instance herzustellen.

Lesersitzung

CLIBefehl:

export READER=aurorapg2.12345678910.us-west-1.rds.amazonaws.com

psql -h $READER

Ausgabe:

psql (15devel, server 10.14)
Type "help" for help.

Setzt eine Umgebungsvariable namens WRITER und versucht, mit diesem Endpunkt eine Verbindung zur DB-Instance herzustellen.

Writer session

CLIBefehl:

export WRITER=aurorapg1.12345678910.us-west-1.rds.amazonaws.com
psql -h $WRITER

Ausgabe:

psql (15devel, server 10.14) 
Type "help" for help.

Die Writer-Sitzung erstellt die Tabelle t1 auf der Writer-Instanz.

Writer session

SQLPostgre-Abfrage:

postgres=> CREATE TABLE t1(b integer);
CREATE TABLE

Wenn es keine widersprüchlichen Abfragen auf dem Writer gibt, wird die ACCESS EXCLUSIVE Sperre für den Writer sofort aufgehoben.

Writer session

ACCESS EXCLUSIVESperre aktiviert

Die Lesesitzung legt ein Sperr-Timeout-Intervall von 100 Millisekunden fest.

Lesersitzung

SQLPostgre-Abfrage:

postgres=> SET lock_timeout=100;
SET

Die Lesersitzung versucht, Daten aus Tabelle t1 auf der Reader-Instanz zu lesen.

Lesersitzung

SQLPostgre-Abfrage:

postgres=> SELECT * FROM t1;

Beispielausgabe:

b
---
(0 rows)

Die Writer-Sitzung löscht t1.

Writer session

SQLPostgre-Abfrage:

postgres=> BEGIN;
BEGIN
postgres=> DROP TABLE t1;
DROP TABLE
postgres=>

Die Abfrage ist abgelaufen und wird im Reader abgebrochen.

Lesersitzung

Postgre-Abfrage: SQL

postgres=> SELECT * FROM t1;

Beispielausgabe:

ERROR:  canceling statement due to lock timeout
LINE 1: SELECT * FROM t1;
                      ^

Um die Ursache des Fehlers zu ermitteln, fragt die Lesersitzung ab und pg_locks pg_stat_activity

Lesersitzung

Postgre-Abfrage: SQL

postgres=> SELECT locktype, relation, mode, backend_type
postgres=> FROM pg_locks l, pg_stat_activity t1
postgres=> WHERE l.pid=t1.pid AND relation = 't1'::regclass::oid;

Das Ergebnis weist darauf hin, dass der aurora wal replay Prozess die Tabelle t1 ACCESS EXCLUSIVE gesperrt hat.

Lesersitzung

Abfrageergebnis:

 locktype | relation |        mode         |   backend_type
----------+----------+---------------------+-------------------
 relation | 68628525 | AccessExclusiveLock | aurora wal replay
(1 row)