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 RDS für PostgreSQL unterstützt.

Context

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 RDS für 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 ANALYSE 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 Wait-Ereignisses empfehlen wir verschiedene Aktionen.

Themen

• Reduzieren Sie die Auswirkungen der Blockierung von SQL-Anweisungen
• Minimieren Sie die Auswirkungen von Wartungsvorgängen

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.