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 Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.

Kontext

Die meisten PostgreSQL-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 generiert Aurora PostgreSQL ein Lock:Relation-Ereignis. Einige gängige Beispiele sind die folgenden:

  • Exklusive Sperren wie ACCESS EXCLUSIVE können alle gleichzeitigen Zugriffe blockieren. Vorgänge in der Datendefinitionssprache (DDL) wie DROP TABLE, TRUNCATE, VACUUM FULL und CLUSTER erwerben implizit ACCESS EXCLUSIVE-Sperren. ACCESS EXCLUSIVE ist auch der Standardsperrmodus für LOCK TABLE-Anweisungen, die keinen Modus explizit angeben.

  • Die Verwendung von CREATE INDEX (without CONCURRENT) für eine Tabelle steht in Konflikt mit den DML-Anweisungen UPDATE, DELETE und INSERT, die ROW EXCLUSIVE-Sperren anfordern.

Weitere Informationen zu Sperren auf Tabellenebene und widersprüchlichen Sperrmodi finden Sie unter Explizite Sperren in der PostgreSQL-Dokumentation.

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 der Blockierung von SQL-Anweisungen

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

  • Verwenden Sie die Option NOWAIT – Einige SQL-Befehle, wie z. B. SELECT- und LOCK-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 Sie SET lock_timeout – Legen Sie einen lock_timeout-Wert fest, um die Zeit zu begrenzen, die eine SQL-Anweisung wartet, um eine Sperre für eine Beziehung zu erhalten. Wenn die Sperre nicht innerhalb des angegebenen Timeouts erworben 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 zum Optimieren von Autovacuum finden Sie unter Arbeiten mit PostgreSQL Autovacuum auf Amazon RDS im Amazon-RDS-Benutzerhandbuch.

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. Die Tabelle enthält eine Abfolge von Abfragen für zwei dieser gleichzeitigen Sitzungen, eine Writer-Sitzung und eine Reader-Sitzung.

Der Wiedergabeprozess wartet die Dauer von max_standby_streaming_delay ab, bevor die Reader-Abfrage 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

Dieses legt eine Umgebungsvariable namens READER mit dem angegebenen Wert fest und versucht, mit diesem Endpunkt eine Verbindung zur DB-Instance herzustellen.

Lesersitzung

CLI-Befehl:

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

psql -h $READER

Ausgabe:

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

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

Writer session

CLI-Befehl:

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

Ausgabe:

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

Die Schreibsitzung erstellt die Tabelle t1 auf der Writer-Instance.

Writer session

PostgreSQL-Abfrage:

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

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

Writer session

ACCESS EXCLUSIVE-Sperre aktiviert

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

Lesersitzung

PostgreSQL-Abfrage:

postgres=> SET lock_timeout=100;
SET

Die Lesesitzung versucht, Daten aus der Tabelle t1 auf der Reader-Instance zu lesen.

Lesersitzung

PostgreSQL-Abfrage:

postgres=> SELECT * FROM t1;

Beispielausgabe:

b
---
(0 rows)

Die Schreibsitzung verwirft t1.

Writer session

PostgreSQL-Abfrage:

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

Die Abfrage ist abgelaufen und wird im Reader abgebrochen.

Lesersitzung

PostgreSQL-Abfrage:

postgres=> SELECT * FROM t1;

Beispielausgabe:

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

Die Lesesitzung fragt pg_locks und pg_stat_activity ab, um die Fehlerursache zu ermitteln.

Lesersitzung

PostgreSQL-Abfrage:

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 zeigt an, dass der aurora wal replay-Prozess eine ACCESS EXCLUSIVE-Sperre für Tabelle t1 hält.

Lesersitzung

Abfrageergebnis:

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