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:transactionid
Das Lock:transactionid
-Ereignis tritt ein, wenn eine Transaktion auf eine Sperre auf Zeilenebene wartet.
Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
Context
Das Ereignis Lock:transactionid
tritt ein, wenn eine Transaktion versucht, eine Sperre auf Zeilenebene zu erlangen, die bereits einer gleichzeitig laufenden Transaktion gewährt wurde. Die Sitzung, die das Lock:transactionid
-Wait-Ereignis anzeigt, ist aufgrund dieser Sperre blockiert. Nachdem die blockierende Transaktion entweder in einer COMMIT
- oder ROLLBACK
-Anweisung endet, kann die blockierte Transaktion fortgesetzt werden.
Die Semantik der Multiversions-Parallelität von Aurora PostgreSQL garantiert, dass Leser keine Autoren blockieren und Autoren Leser nicht blockieren. Damit Konflikte auf Zeilenebene auftreten können, müssen blockierende und blockierte Transaktionen widersprüchliche Anweisungen der folgenden Typen ausgeben:
-
UPDATE
-
SELECT … FOR UPDATE
-
SELECT … FOR KEY SHARE
Die Anweisung SELECT … FOR KEY SHARE
ist ein Sonderfall. Die Datenbank verwendet die Klausel FOR KEY
SHARE
, um die Leistung der referenziellen Integrität zu optimieren. Eine Sperre auf Zeilenebene für eine Zeile kann INSERT
-, UPDATE
- und DELETE
-Befehle für andere Tabellen blockieren, die auf die Zeile verweisen.
Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn dieses Ereignis mehr als normal auftritt, sind die Ursache normalerweise UPDATE
-, SELECT …
FOR UPDATE
-, SELECT … FOR KEY SHARE
-Anweisungen in Kombination mit den folgenden Bedingungen.
Hohe Gleichzeitigkeit
Aurora PostgreSQL kann eine körnige Sperrsemantik auf Zeilenebene verwenden. Die Wahrscheinlichkeit von Konflikten auf Zeilenebene steigt, wenn die folgenden Bedingungen erfüllt sind:
-
Eine sehr gleichzeitige Workload beansprucht dieselben Zeilen.
-
Parallelbetrieb steigt.
Leerlauf in Transaktion
Manchmal zeigt die Spalte pg_stat_activity.state
den Wert idle in transaction
an. Dieser Wert wird für Sitzungen angezeigt, die eine Transaktion gestartet, aber noch kein COMMIT
oder ROLLBACK
ausgegeben haben. Wenn der pg_stat_activity.state
-Wert nicht active
ist, ist die in pg_stat_activity
angezeigte Abfrage die letzte, die ausgeführt wurde. Die blockierende Sitzung verarbeitet eine Abfrage nicht aktiv, da eine offene Transaktion eine Sperre hält.
Wenn eine Leerlauf-Transaktion eine Sperre auf Zeilenebene erworben hat, kann dies verhindern, dass andere Sitzungen sie erwerben. Diese Bedingung führt zu einem häufigen Auftreten des Warteereignisses Lock:transactionid
. Um das Problem zu diagnostizieren, überprüfen Sie die Ausgabe von pg_stat_activity
und pg_locks
.
Lang laufende Transaktionen
Transaktionen, die lange laufen, erhalten lange Zeit Sperren. Diese langjährigen Sperren können die Ausführung anderer Transaktionen verhindern.
Aktionen
Zeilensperre ist ein Konflikt zwischen UPDATE
-, SELECT … FOR
UPDATE
- oder SELECT … FOR KEY SHARE
-Anweisungen. Bevor Sie eine Lösung versuchen, sollten Sie herausfinden, wann diese Anweisungen in derselben Zeile ausgeführt werden. Wählen Sie mit diesen Informationen eine in den folgenden Abschnitten beschriebene Strategie aus.
Themen
Reagieren auf hohe Parallelbetrieb
Wenn Parallelität das Problem darstellt, versuchen Sie eine der folgenden Techniken:
-
Senken Sie die Parallelität in der Anwendung. Verringern Sie beispielsweise die Anzahl der aktiven Sitzungen.
-
Implementieren Sie einen Verbindungspool. Informationen zum Poolen von Verbindungen mit RDS-Proxy finden Sie unter Amazon RDS Proxy für Aurora verwenden.
-
Entwerfen Sie die Anwendung oder das Datenmodell, um konkurrierende
UPDATE
- undSELECT … FOR UPDATE
-Anweisungen zu vermeiden. Sie können auch die Anzahl der Fremdschlüssel verringern, auf die vonSELECT … FOR KEY SHARE
-Anweisungen zugegriffen wird.
Reagieren Sie auf ungenutzte Transaktionen
Wenn pg_stat_activity.state
idle in transaction
anzeigt, verwenden Sie die folgenden Strategien:
-
Schalten Sie nach Möglichkeit Autocommit ein. Dieser Ansatz verhindert, dass Transaktionen andere Transaktionen blockieren, während sie auf ein
COMMIT
oderROLLBACK
warten. -
Suchen Sie nach Codepfaden, denen
COMMIT
,ROLLBACK
oderEND
fehlt. -
Stellen Sie sicher, dass die Ausnahmebehandlungslogik in Ihrer Anwendung immer einen Pfad zu einem gültigen
end of transaction
hat. -
Stellen Sie sicher, dass Ihre Anwendung Abfrageergebnisse verarbeitet, nachdem die Transaktion mit
COMMIT
oderROLLBACK
beendet wurde.
Reagieren Sie auf lang andauernde Transaktionen
Wenn Transaktionen mit langer Laufzeit das häufige Auftreten von Lock:transactionid
verursachen, versuchen Sie die folgenden Strategien:
-
Halten Sie Zeilensperren von lang andauernden Transaktionen fern.
-
Beschränken Sie die Länge von Abfragen, indem Sie nach Möglichkeit Autocommit implementieren.