Lock:Relation - Amazon Aurora
Versioni del motore supportateContestoProbabili cause di aumento delle atteseAzioni

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:Relation

L’evento Lock:Relation si verifica quando una query è in attesa di acquisire un blocco su una tabella o vista (relazione) attualmente bloccata da un’altra transazione.

Versioni del motore supportate

Queste informazioni relative all’evento di attesa sono supportate per tutte le versioni di Aurora PostgreSQL.

Contesto

La maggior parte dei comandi PostgreSQL utilizza implicitamente i blocchi per controllare l’accesso simultaneo ai dati nelle tabelle. È inoltre possibile utilizzare questi blocchi esplicitamente nel codice dell’applicazione con il comando LOCK. Molte modalità di blocco non sono compatibili tra loro e possono bloccare le transazioni quando cercano di accedere allo stesso oggetto. Quando ciò accade, Aurora PostgreSQL genera un evento Lock:Relation. Di seguito sono riportati alcuni esempi comuni:

  • Blocchi esclusivi come ACCESS EXCLUSIVE possono bloccare tutti gli accessi simultanei. Le operazioni DDL (Data Definition Language) come DROP TABLE, TRUNCATE, VACUUM FULL, e CLUSTER acquisiscono implicitamente i blocchi ACCESS EXCLUSIVE. ACCESS EXCLUSIVE è anche la modalità di blocco predefinita per le istruzioni LOCK TABLE che non specificano esplicitamente una modalità.

  • L’uso di CREATE INDEX (without CONCURRENT) su una tabella è in conflitto con le istruzioni DML (Data Manipulation Language) UPDATE, DELETE, e INSERT, che acquisiscono i blocchi ROW EXCLUSIVE.

Per ulteriori informazioni sui blocchi a livello di tabella e sulle modalità di blocco in conflitto, vedere Blocco esplicito nella documentazione di PostgreSQL.

Il blocco di query e transazioni in genere si sblocca in uno dei seguenti modi:

  • Query di blocco: l’applicazione può annullare la query o l’utente può terminare il processo. Il motore può anche forzare la fine della query a causa del timeout dell’istruzione di una sessione o di un meccanismo di rilevamento del deadlock.

  • Blocco della transazione: una transazione smette di bloccarsi quando esegue un’istruzione ROLLBACK o COMMIT. I rollback si verificano automaticamente anche quando le sessioni vengono disconnesse da un client o da problemi di rete o terminano. Le sessioni possono essere terminate quando il motore di database è spento, quando il sistema è fuori memoria e così via.

Probabili cause di aumento delle attese

Quando l’evento Lock:Relation si verifica più frequentemente del normale, può indicare un problema di prestazioni. Le cause tipiche sono:

Sessioni simultanee aumentate con blocchi di tabella in conflitto

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

Operazioni di manutenzione

Le operazioni di manutenzione Health come VACUUM e ANALYZE possono aumentare significativamente il numero di blocchi in conflitto. VACUUM FULL acquisisce un blocco ACCESS EXCLUSIVE, e ANALYZE acquisisce un blocco SHARE UPDATE EXCLUSIVE. Entrambi i tipi di blocchi possono causare un evento di attesa Lock:Relation. Le operazioni di manutenzione dei dati delle applicazioni, come l’aggiornamento di una vista materializzata, possono anche aumentare le query e le transazioni bloccate.

Blocchi sulle istanze del lettore

È possibile che si verifichi un conflitto tra i blocchi di relazione tenuti dallo scrittore e dai lettori. Attualmente solo i blocchi di relazione ACCESS EXCLUSIVE vengono replicati nelle istanze del lettore. Tuttavia, il blocco di relazione ACCESS EXCLUSIVE sarà in conflitto con qualsiasi blocco di relazione ACCESS SHARE tenuto dal lettore. Questo conflitto può causare un aumento degli eventi di attesa della relazione di blocco sul lettore.

Azioni

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

Riduci l’impatto del blocco delle istruzioni SQL

Per ridurre l’impatto del blocco delle istruzioni SQL, modificare il codice dell’applicazione laddove possibile. Di seguito sono riportate due tecniche comuni per ridurre i blocchi:

  • Utilizzo dell’opzione NOWAIT — Alcuni comandi SQL, come le istruzioni SELECT e LOCK, supportano questa opzione. La direttiva NOWAIT annulla la query richiedente il blocco se il blocco non può essere acquisito immediatamente. Questa tecnica può aiutare a impedire che una sessione di blocco provochi un accumulo di sessioni bloccate dietro di essa.

    Ad esempio: si supponga che la transazione A sia in attesa di un blocco trattenuto dalla transazione B. Ora, se B richiede un blocco su una tabella bloccata dalla transazione C, la transazione A potrebbe essere bloccata fino al completamento della transazione C. Ma se la transazione B utilizza un NOWAIT quando richiede il blocco su C, può fallire rapidamente e garantire che la transazione A non debba attendere indefinitamente.

  • Utilizza SET lock_timeout — Imposta un valore lock_timeout per limitare il tempo in cui un’istruzione SQL attende di acquisire un blocco su una relazione. Se il blocco non viene acquisito entro il timeout specificato, la transazione che richiede il blocco viene annullata. Impostare questo valore a livello di sessione.

Riduci al minimo l’effetto delle operazioni di manutenzione

Operazioni di manutenzione come VACUUM e ANALYZE sono importanti. Si consiglia di non spegnerli qualora vengano trovati eventi di attesa Lock:Relation relativi a queste operazioni di manutenzione. I seguenti approcci possono ridurre al minimo l’effetto di queste operazioni:

  • Eseguire manualmente le operazioni di manutenzione durante le ore non di punta.

  • Per ridurre le attese Lock:Relation causate da attività autovacuum, eseguire qualsiasi sintonizzazione automatica necessaria. Per informazioni sulla sintonizzazione autovacuum, fai riferimento a Funzionamento di PostgreSQL Autovacuum in Amazon RDS nella Guida per l’utente di Amazon RDS.

Verifica la presenza di blocchi del lettore

Puoi vedere come le sessioni simultanee su uno scrittore e sui lettori potrebbero tenere blocchi che si bloccano a vicenda. A questo scopo, puoi eseguire le query che restituiscono il tipo di blocco e la relazione. Nella tabella è possibile trovare una sequenza di query su due sessioni simultanee, una sessione di scrittura e una sessione di lettura.

Il processo di riproduzione attende la durata impostata per max_standby_streaming_delay prima di annullare la query dell’istanza di lettura. Come mostrato nell’esempio, il timeout di blocco di 100 ms è ben al di sotto del valore di default di max_standby_streaming_delay di 30 secondi. Il timeout di blocco si verifica prima che si verifichi un problema.

Evento di sequenza Sessione Comando o output

Imposta una variabile di ambiente denominata READER con il valore specificato e tenta di connettersi all’istanza database con questo endpoint.

Sessione lettore

Comando della CLI:

export READER=aurorapg2.12345678910.us-west-1.rds.amazonaws.com

psql -h $READER

Output:

psql (15devel, server 10.14)
Type "help" for help.

Imposta una variabile di ambiente denominata WRITER e tenta di connettersi all’istanza database con questo endpoint.

Sessione di scrittura

Comando della CLI:

export WRITER=aurorapg1.12345678910.us-west-1.rds.amazonaws.com
psql -h $WRITER

Output:

psql (15devel, server 10.14) 
Type "help" for help.

La sessione di scrittura crea la tabella t1 sull’istanza di scrittura.

Sessione di scrittura

Query PostgreSQL:

postgres=> CREATE TABLE t1(b integer);
CREATE TABLE

Se non ci sono query in conflitto sullo scrittore, il blocco ACCESS EXCLUSIVE viene acquisito immediatamente sull’istanza di scrittura.

Sessione di scrittura

Blocco ACCESS EXCLUSIVE abilitato

La sessione del lettore imposta un intervallo di timeout di blocco di 100 millisecondi.

Sessione lettore

Query PostgreSQL:

postgres=> SET lock_timeout=100;
SET

La sessione dell’istanza di lettura tenta di leggere i dati dalla tabella t1 sull’istanza di lettura.

Sessione lettore

Query PostgreSQL:

postgres=> SELECT * FROM t1;

Output di esempio:

b
---
(0 rows)

La sessione di scrittura elimina t1.

Sessione di scrittura

Query PostgreSQL:

postgres=> BEGIN;
BEGIN
postgres=> DROP TABLE t1;
DROP TABLE
postgres=>

La query scade e viene annullata sul lettore.

Sessione lettore

Query PostgreSQL:

postgres=> SELECT * FROM t1;

Output di esempio:

ERROR:  canceling statement due to lock timeout
LINE 1: SELECT * FROM t1;
                      ^

Per determinare la causa dell’errore, la sessione dell’istanza di lettura interroga pg_locks e pg_stat_activity.

Sessione lettore

Query PostgreSQL:

postgres=> SELECT locktype, relation, mode, backend_type
postgres=> FROM pg_locks l, pg_stat_activity t1
postgres=> WHERE l.pid=t1.pid AND relation = 't1'::regclass::oid;

Il risultato indica che il processo aurora wal replay è in possesso di un blocco ACCESS EXCLUSIVE sulla tabella t1.

Sessione lettore

Risultato della query:

 locktype | relation |        mode         |   backend_type
----------+----------+---------------------+-------------------
 relation | 68628525 | AccessExclusiveLock | aurora wal replay
(1 row)