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 RDS per PostgreSQL.

Context

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, RDS per 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 ANALYSE 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.

Operazioni

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

Argomenti

• Riduci l'impatto del blocco delle istruzioni SQL
• Riduci al minimo l'effetto delle operazioni di manutenzione

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.