Lock:extend - Amazon Relational Database Service

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Lock:extend

L’evento Lock:extend si verifica quando un processo di back-end è in attesa di bloccare una relazione per estenderla mentre un altro processo ha un blocco su tale relazione per lo stesso scopo.

Versioni del motore supportate

Queste informazioni relative all'evento di attesa sono supportate per tutte le versioni di RDS per PostgreSQL.

Context

L'evento Lock:extend indica che un processo di back-end è in attesa di estendere una relazione su cui un altro processo di backend mantiene un blocco mentre sta estendendo tale relazione. Poiché solo un processo alla volta può estendere una relazione, il sistema genera un evento di attesa Lock:extend. Le operazioni INSERT, COPY, e UPDATE possono generare questo evento.

Probabili cause di aumento delle attese

Quando l'evento Lock:extend si verifica più del normale, probabilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti.

Aumento degli inserti simultanei o degli aggiornamenti della stessa tabella

Potrebbe esserci un aumento del numero di sessioni simultanee con query che inseriscono o aggiornano la stessa tabella.

Larghezza di banda di rete insufficiente

La larghezza di banda di rete sull'istanza database potrebbe essere insufficiente per le esigenze di comunicazione di storage del carico di lavoro corrente. Ciò può contribuire alla latenza dello storage che causa un aumento degli eventi Lock:extend.

Operazioni

Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.

Riduci gli inserti e gli aggiornamenti simultanei alla stessa relazione

Innanzitutto, determinare se c'è un aumento dei parametri tup_inserted e tup_updated e un aumento di questi eventi di attesa. In tal caso, verificare quali relazioni sono in forte contesa per le operazioni di inserimento e aggiornamento. Per determinarlo, interrogare la vista pg_stat_all_tables per i valori nei campi n_tup_ins e n_tup_upd. Per ulteriori informazioni sulla vista pg_stat_all_tables, consultare pg_stat_all_tables nella documentazione PostgreSQL.

Per ottenere ulteriori informazioni sul blocco e le query bloccate, eseguire una query pg_stat_activity come nel seguente esempio:

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

Dopo aver identificato le relazioni che contribuiscono ad aumentare gli eventi Lock:extend, utilizza le seguenti tecniche per ridurre la contesa:

  • Scopri se è possibile utilizzare il partizionamento per ridurre le contese per la stessa tabella. La separazione delle tuple inserite o aggiornate in diverse partizioni può ridurre le contese. Per informazioni sulle partizioni, consulta Gestione delle partizioni PostgreSQL con l'estensione pg_partman.

  • Se l'evento di attesa è dovuto principalmente all'attività di aggiornamento, considerare di ridurre il valore del fattore di riempimento della relazione. Ciò può ridurre le richieste di nuovi blocchi durante l'aggiornamento. Il fattore di riempimento è un parametro di archiviazione per una tabella che determina la quantità massima di spazio per l'imballaggio di una pagina di tabella. Viene espresso come percentuale dello spazio totale per una pagina. Per ulteriori informazioni sul parametro fillfactor, consulta CREA TABELLA nella documentazione di PostgreSQL.

    Importante

    Si consiglia vivamente di testare il sistema se si modifica il fattore di riempimento perché la modifica di questo valore può influire negativamente sulle prestazioni, a seconda del carico di lavoro.

Aumentare la larghezza di banda di rete

Per vedere se c'è un aumento della latenza di scrittura, controlla il parametro WriteLatency in CloudWatch. Se è presente, usa le metriche Amazon CloudWatch WriteThroughput e ReadThroughput per monitorare il traffico relativo all'archiviazione sull'istanza database. Questi parametri possono aiutarti a determinare se la larghezza di banda della rete è sufficiente per il tuo carico di lavoro.

Se la larghezza di banda della rete non è sufficiente, aumentala. Se il file client o l’istanza DB sta raggiungendo i limiti di larghezza di banda di rete, l'unico modo per aumentare la larghezza di banda è aumentare la dimensione dell'istanza DB.

Per ulteriori informazioni sui parametri di CloudWatch, consultare Parametri a CloudWatch livello di istanza Amazon per Amazon RDS. Per informazioni sulle prestazioni di rete per una classe di istanza database, consulta Parametri a CloudWatch livello di istanza Amazon per Amazon RDS.