Lock:tuple

Das Lock:tuple-Ereignis tritt ein, wenn ein Backend-Prozess darauf wartet, eine Sperre für ein Tupel zu erlangen.

Unterstützte Engine-Versionen

Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.

Context

Das Ereignis Lock:tuple zeigt an, dass ein Back-End darauf wartet, eine Sperre für ein Tupel zu erlangen, während ein anderes Back-End eine widersprüchliche Sperre für dasselbe Tupel hält. Die folgende Tabelle veranschaulicht ein Szenario, in dem Sitzungen das Lock:tuple-Ereignis generieren.

Zeit	1. Sitzung	2. Sitzung	3. Sitzung
t1	Startet eine Transaktion.
t2	Aktualisiert Zeile 1.
t3		Aktualisiert Zeile 1. Die Sitzung erwirbt eine exklusive Sperre für das Tupel und wartet dann darauf, dass Sitzung 1 die Sperre durch Commit oder Rollback freigibt.
t4			Aktualisiert Zeile 1. Die Sitzung wartet darauf, dass Sitzung 2 die exklusive Sperre für das Tupel freigibt.

Oder Sie können dieses Warteereignis simulieren, indem Sie das Benchmarking-Tool pgbench verwenden. Konfigurieren Sie eine hohe Anzahl gleichzeitiger Sitzungen, um dieselbe Zeile in einer Tabelle mit einer benutzerdefinierten SQL-Datei zu aktualisieren.

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

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Wenn dieses Ereignis mehr als normal auftritt und möglicherweise auf ein Leistungsproblem hinweist, sind typische Ursachen:

• Eine große Anzahl gleichzeitiger Sitzungen versucht, eine widersprüchliche Sperre für dasselbe Tupel zu erlangen, indem sie UPDATE- oder DELETE-Anweisungen ausführen.

• In hochgradig gleichzeitigen Sitzungen wird eine SELECT-Anweisung ausgeführt, die den FOR UPDATE- oder FOR NO KEY UPDATE-Sperrmodus verwendet.

• Verschiedene Faktoren veranlassen Anwendungs- oder Verbindungspools dazu, weitere Sitzungen zu öffnen, um dieselben Vorgänge auszuführen. Wenn neue Sitzungen versuchen, dieselben Zeilen zu ändern, kann die DB-Last stark ansteigen und Lock:tuple kann erscheinen.

Weitere Informationen finden Sie unter Sperren auf Zeilenebene in der PostgreSQL-Dokumentation.

Aktionen

Abhängig von den Ursachen Ihres Wait-Ereignisses empfehlen wir verschiedene Aktionen.

Themen

• Untersuchen Sie Ihre Anwendungslogik
• Finde die Blocker-Sitzung
• Reduzieren Sie Parallelität, wenn es hoch ist
• Beheben von Engpässen

Untersuchen Sie Ihre Anwendungslogik

Finden Sie heraus, ob sich eine Blocker-Sitzung schon lange im idle in transaction-Zustand befindet. Wenn ja, erwägen Sie, die Blocker-Sitzung als kurzfristige Lösung zu beenden. Sie können die Funktion pg_terminate_backend verwenden. Weitere Informationen zu dieser Funktion finden Sie unter Server-Signalisierungsfunktionen in der PostgreSQL-Dokumentation.

Gehen Sie für eine langfristige Lösung wie folgt vor:

• Passen Sie die Anwendungslogik an.

• Verwenden Sie den Parameter idle_in_transaction_session_timeout. Dieser Parameter beendet jede Sitzung mit einer offenen Transaktion, die länger als die angegebene Zeitspanne im Leerlauf ist. Weitere Informationen finden Sie unter Standardeinstellungen für Clientverbindungen in der PostgreSQL-Dokumentation.

• Verwenden Sie Autocommit so weit wie möglich. Weitere Informationen finden Sie unter SET AUTOCOMMIT in der PostgreSQL-Dokumentation.

Finde die Blocker-Sitzung

Identifizieren Sie während des Lock:tuple-Wait-Ereignisses den Blocker und die blockierte Sitzung, indem Sie herausfinden, welche Sperren voneinander abhängen. Weitere Informationen finden Sie unter Informationen zur Sperrabhängigkeit im PostgreSQL-Wiki.

Im folgenden Beispiel werden alle Sitzungen abgefragt, nach tuple gefiltert und nach wait_time sortiert.

SELECT blocked_locks.pid AS blocked_pid,
         blocking_locks.pid AS blocking_pid,
         blocked_activity.usename AS blocked_user,
         blocking_activity.usename AS blocking_user,
         now() - blocked_activity.xact_start AS blocked_transaction_duration,
         now() - blocking_activity.xact_start AS blocking_transaction_duration,
         concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
         concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
         blocked_activity.state AS blocked_state,
         blocking_activity.state AS blocking_state,
         blocked_locks.locktype AS blocked_locktype,
         blocking_locks.locktype AS blocking_locktype,
         blocked_activity.query AS blocked_statement,
         blocking_activity.query AS blocking_statement
    FROM pg_catalog.pg_locks blocked_locks
    JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
    JOIN pg_catalog.pg_locks blocking_locks
        ON blocking_locks.locktype = blocked_locks.locktype
        AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
        AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
        AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
        AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
        AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
        AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
        AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
        AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
        AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
        AND blocking_locks.pid != blocked_locks.pid
    JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
    WHERE NOT blocked_locks.GRANTED;

Reduzieren Sie Parallelität, wenn es hoch ist

Das Lock:tuple-Ereignis kann ständig auftreten, insbesondere in einer arbeitsreichen Zeit. Erwägen Sie in dieser Situation, die hohe Parallelität für sehr belegte Reihen zu reduzieren. Oft steuern nur wenige Zeilen eine Warteschlange oder die boolesche Logik, was diese Zeilen sehr ausgelastet macht.

Sie können die Parallelität reduzieren, indem Sie verschiedene Ansätze verwenden, die auf der Geschäftsanforderung, der Anwendungslogik und dem Workload-Typ basieren. Sie können z. B. Folgendes tun:

• Gestalten Sie Ihre Tabellen- und Datenlogik neu, um hohe Parallelität zu reduzieren.

• Ändern Sie die Anwendungslogik, um die hohe Parallelität auf Zeilenebene zu reduzieren.

• Nutzen und gestalten Sie Abfragen mit Sperren auf Zeilenebene.

• Verwenden Sie die NOWAIT-Klausel mit Wiederholungsvorgänge.

• Erwägen Sie, optimistische und hybridsperrende Logik-Parallelitätssteuerung zu nutzen.

• Überlegen Sie, die Isolationsstufe der Datenbank zu ändern.

Beheben von Engpässen

Das Lock:tuple kann bei Engpässen wie CPU-Aushungerungen oder maximaler Nutzung der Amazon EBS-Bandbreite auftreten. Um Engpässe zu verringern, sollten Sie die folgenden Ansätze berücksichtigen:

• Skalieren Sie Ihren Instance-Klassentyp hoch.

• Optimieren Sie ressourcenintensive Abfragen.

• Ändern Sie die Anwendungslogik.

• Archivieren Sie Daten, die selten zugegriffen wird.