Lock:transactionid - Amazon Relational Database Service
Unterstützte Engine-VersionenContextWahrscheinliche 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: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 RDS für 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 RDS für 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

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

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 Verwenden von Amazon RDS Proxy.

  • Entwerfen Sie die Anwendung oder das Datenmodell, um konkurrierende UPDATE- und SELECT … FOR UPDATE-Anweisungen zu vermeiden. Sie können auch die Anzahl der Fremdschlüssel verringern, auf die von SELECT … 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 oder ROLLBACK warten.

  • Suchen Sie nach Codepfaden, denen COMMIT, ROLLBACK oder END 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 oder ROLLBACK 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.