Lock:extend

Das Lock:extend-Ereignis tritt ein, wenn ein Backend-Prozess darauf wartet, eine Beziehung zu sperren, um sie zu erweitern, während ein anderer Prozess diese Beziehung für denselben Zweck gesperrt hat.

Unterstützte Engine-Versionen

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

Context

Das Ereignis Lock:extend zeigt an, dass ein Backend-Prozess darauf wartet, eine Beziehung zu erweitern, für die ein anderer Backend-Prozess eine Sperre hält, während er diese Beziehung erweitert. Da jeweils nur ein Prozess eine Beziehung erweitern kann, generiert das System ein Lock:extend-Warteereignis. INSERT-, COPY- und UPDATE-Vorgänge können dieses Ereignis erzeugen.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Wenn das Lock:extend-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:

Anstieg der gleichzeitigen Einfügungen oder Aktualisierungen derselben Tabelle

Es kann zu einer Zunahme der Anzahl gleichzeitiger Sitzungen mit Abfragen kommen, die in dieselbe Tabelle einfügen oder aktualisieren.

Unzureichende Netzwerkbandbreite

Die Netzwerkbandbreite auf der DB-Instance reicht möglicherweise nicht aus, um die Speicherkommunikationsanforderungen der aktuellen Workload zu gewährleisten. Dies kann zu einer Speicherlatenz führen, die zu einem Anstieg der Lock:extend-Ereignisse führt.

Aktionen

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

Themen

• Reduzieren Sie gleichzeitige Einfügungen und Aktualisierungen auf dieselbe Beziehung
• Erhöhung der Netzwerkbandbreite

Reduzieren Sie gleichzeitige Einfügungen und Aktualisierungen auf dieselbe Beziehung

Stellen Sie zunächst fest, ob die tup_inserted- und tup_updated-Metriken und damit auch dieses Warteereignis gestiegen ist. Überprüfen Sie in diesem Fall, welche Beziehungen für Einfüge- und Aktualisierungsvorgänge in hohem Streit stehen. Um dies zu ermitteln, fragen Sie die pg_stat_all_tables-Ansicht nach den Werten in den n_tup_ins- und n_tup_upd-Feldern ab. Informationen zur Ansicht pg_stat_all_tables finden Sie unter pg_stat_all_tables in der PostgreSQL-Dokumentation.

Um weitere Informationen über das Blockieren und blockierte Abfragen zu erhalten, fragen Sie pg_stat_activity wie im folgenden Beispiel ab:

SELECT
    blocked.pid,
    blocked.usename,
    blocked.query,
    blocking.pid AS blocking_id,
    blocking.query AS blocking_query,
    blocking.wait_event AS blocking_wait_event,
    blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
 
   pid  | usename  |            query             | blocking_id |                         blocking_query                           | blocking_wait_event | blocking_wait_event_type
  ------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
   7143 |  myuser  | insert into tab1 values (1); |        4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend      | IO

Nachdem Sie Beziehungen identifiziert haben, die zur Erhöhung von Lock:extend-Ereignissen beitragen, verwenden Sie die folgenden Techniken, um die Konflikte zu reduzieren:

• Finden Sie heraus, ob Sie Partitionierung verwenden können, um die Konflikte für dieselbe Tabelle zu reduzieren. Das Trennen eingefügter oder aktualisierter Tupel in verschiedene Partitionen kann die Konflikte verringern. Weitere Informationen zur Partitionierung finden Sie unter Verwalten von PostgreSQL-Partitionen mit der Erweiterung pg_partman.

• Wenn das Warteereignis hauptsächlich auf Aktualisierungsaktivitäten zurückzuführen ist, sollten Sie erwägen, den Füllfaktor-Wert der Beziehung zu reduzieren. Dies kann Anfragen nach neuen Blöcken während des Updates reduzieren. Der Füllfaktor ist ein Speicherparameter für eine Tabelle, der den maximalen Speicherplatz zum Packen einer Tabellenseite bestimmt. Es wird als Prozentsatz des gesamten Speicherplatzes für eine Seite ausgedrückt. Weitere Informationen zum Parameter fillfactor finden Sie unter CREATE TABLE in der PostgreSQL-Dokumentation.

  Wichtig

  Wir empfehlen dringend, Ihr System zu testen, wenn Sie den Füllfaktor ändern, da sich die Änderung dieses Wertes je nach Workload negativ auf die Leistung auswirken kann.

Erhöhung der Netzwerkbandbreite

Um zu sehen, ob die Schreiblatenz zunimmt, überprüfen Sie die WriteLatency-Metrik in CloudWatch. Wenn dies der Fall ist, verwenden Sie die Amazon-CloudWatch-Metriken WriteThroughput und ReadThroughput, um den speicherbezogenen Datenverkehr auf der DB-Instance zu überwachen. Diese Metriken können Ihnen helfen festzustellen, ob die Netzwerkbandbreite für die Speicheraktivität Ihrer Workload ausreicht.

Wenn Ihre Netzwerkbandbreite nicht ausreicht, erhöhen Sie sie. Wenn Ihre DB-Instance die Grenzen der Netzwerkbandbreite erreicht, besteht die einzige Möglichkeit, die Bandbreite zu erhöhen, darin, die Größe Ihrer DB-Instance zu erhöhen.

Weitere Informationen zu CloudWatch-Metriken finden Sie unter CloudWatch Amazon-Instanzmetriken für Amazon RDS. Informationen zur Netzwerkleistung für jede DB-Instance-Klasse finden Sie unter CloudWatch Amazon-Instanzmetriken für Amazon RDS.