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à.
LWLock:lock_manager
Questo evento si verifica quando il motore Aurora PostgreSQL mantiene l'area di memoria del blocco condiviso per allocare, controllare e dislocare un blocco quando non è possibile un blocco rapido del percorso.
Versioni del motore supportate
Queste informazioni relative all'evento di attesa sono supportate per Aurora PostgreSQL versione 9.6 e successive.
Context
Quando si emette un'istruzione SQL, Aurora PostgreSQL registra i blocchi per proteggere la struttura, i dati e l'integrità del database durante le operazioni simultanee. Il motore può raggiungere questo obiettivo utilizzando un blocco veloce del percorso o un blocco del percorso che non è veloce. Un blocco del percorso che non è veloce è più costoso e crea più sovraccarico di un blocco veloce del percorso.
Blocco rapido del percorso
Per ridurre il sovraccarico dei blocchi che vengono presi e rilasciati frequentemente, ma che raramente sono in conflitto, i processi di backend possono utilizzare il blocco rapido del percorso. Il database utilizza questo meccanismo per i blocchi che soddisfano i seguenti criteri:
-
Usano il metodo di blocco DEFAULT.
-
Rappresentano un blocco su una relazione di database anziché una relazione condivisa.
-
Sono blocchi deboli che difficilmente entrino in conflitto.
-
Il motore può verificare rapidamente che non siano presenti blocchi in conflitto.
Il motore non può utilizzare il blocco rapido del percorso quando una di queste condizioni è vera:
-
Il blocco non soddisfa i criteri precedenti.
-
Non sono disponibili più slot per il processo di backend.
Per ulteriori informazioni sul blocco rapido del percorso, consulta percorso rapido
Esempio di problema di scalabilità per il blocco manager
In questo esempio, una tabella denominata purchases memorizza cinque anni di dati, partizionati per giorno. Ogni partizione ha due indici. Si verifica la seguente sequenza di eventi:
-
Si interrogano dati su diversi giorni, il che richiede al database di leggere molte partizioni.
-
Il database crea una voce di blocco per ogni partizione. Se gli indici di partizione fanno parte del percorso di accesso dell'ottimizzatore, il database crea anche una voce di blocco per loro.
-
Quando il numero di voci di blocco richieste per lo stesso processo di back-end è superiore a 16, ovvero il valore di
FP_LOCK_SLOTS_PER_BACKEND, il gestore di blocco utilizza il metodo di blocco del percorso non veloce.
Le applicazioni moderne potrebbero avere centinaia di sessioni. Se le sessioni simultanee eseguono una query sul genitore senza un'adeguata scrematura delle partizioni, il database potrebbe creare centinaia o addirittura migliaia di blocchi di percorso non veloci. In genere, quando questa concorrenza è superiore al numero di vCPU, appare l’evento di attesa LWLock:lock_manager.
Nota
L’evento di attesa LWLock:lock_manager non è correlato al numero di partizioni o indici in uno schema di database. Al contrario, è correlato al numero di blocchi di percorso non veloci che il database deve controllare.
Probabili cause di aumento delle attese
Quando l’evento di attesa LWLock:lock_manager si verifica più del normale, probabilmente indicando un problema di prestazioni, le cause più probabili di picchi improvvisi sono le seguenti:
-
Le sessioni attive simultanee eseguono query che non utilizzano blocchi di percorso veloci. Queste sessioni superano anche la vCPU massima.
-
Un gran numero di sessioni attive simultanee sta accedendo a una tabella fortemente partizionata. Ogni partizione ha più indici.
-
Il database sta vivendo una tempesta di connessione. Per impostazione predefinita, alcune applicazioni e software del connection pool creano più connessioni quando il database è lento. Questa pratica peggiora il problema. Ottimizza il software del pool di connessioni in modo che non si verifichino tempeste di connessione.
-
Un numero elevato di sessioni esegue una query su una tabella padre senza potare le partizioni.
-
Un DDL (Data Definition Language), DML (Data Manipolation Language) o un comando di manutenzione blocca esclusivamente una relazione occupata o tuple a cui si accede frequentemente o modificate.
Operazioni
Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.
Argomenti
Usare la potatura delle partizioni
Potatura delle partizioni è una strategia di ottimizzazione delle query che esclude le partizioni non necessarie dalle scansioni di tabelle, migliorando così le prestazioni. La potatura delle partizioni è attivata per impostazione predefinita. Se è spento, accenderlo come segue.
SET enable_partition_pruning = on;
Le query possono trarre vantaggio dalla potatura delle partizioni quando la clausola WHERE contiene la colonna utilizzata per il partizionamento. Per ulteriori informazioni, consulta Potatura delle partizioni
Rimuovere indici non necessari
Il database potrebbe contenere indici inutilizzati o usati raramente. In tal caso, considera la possibilità di eliminarli. Eseguire una delle operazioni seguenti:
-
Scopri come trovare indici non necessari consultanto Indici non utilizzati
nel wiki di PostgreSQL. -
Esegui PG Collector. Questo script SQL raccoglie le informazioni del database e le presenta in un report HTML consolidato. Controlla la sezione «Indici non utilizzati». Per ulteriori informazioni, consulta pg-collector
nel repository AWS Labs GitHub.
Ottimizza le tue query per bloccare rapidamente i percorsi
Per scoprire se le tue query utilizzano il blocco rapido dei percorsi, esegui una query nella colonna fastpath della tabella pg_locks. Se le query non utilizzano il blocco rapido dei percorsi, provare a ridurre il numero di relazioni per query a meno di 16.
Sintonizzati per altri eventi di attesa
Se LWLock:lock_manager è il primo o il secondo nell'elenco delle prime attese, controlla se nell'elenco vengono visualizzati anche i seguenti eventi di attesa:
-
Lock:Relation -
Lock:transactionid -
Lock:tuple
Se gli eventi precedenti appaiono in alto nell'elenco, prendi in considerazione prima l'ottimizzazione di questi eventi di attesa. Questi eventi possono essere un driver per LWLock:lock_manager.
Riduzione dei colli di bottiglia hardware
Potresti avere un collo di bottiglia hardware, come la fame di CPU o il massimo utilizzo della larghezza di banda Amazon EBS. In questi casi, valuta la riduzione dei colli di bottiglia hardware. Prendi in considerazione le seguenti azioni:
-
Ridimensiona la tua classe di istanza.
-
Ottimizza le query che consumano grandi quantità di CPU e memoria.
-
Cambia la logica dell'applicazione.
-
Archivia i tuoi dati.
Per ulteriori informazioni su CPU, memoria e larghezza di banda di rete EBS, vedere Tipi di istanza Amazon RDS
Utilizzare un connection pooler
Se il numero totale di connessioni attive supera la vCPU massima, più processi del sistema operativo richiedono CPU di quella supportata dal tipo di istanza. In questo caso, valuta l'utilizzo o l'ottimizzazione di un connection pool. Per ulteriori informazioni sul numero di vCPU per ogni tipo di istanza, consulta Tipi di istanza di Amazon RDS
Per ulteriori informazioni sul connection pool, consulta le risorse seguenti:
-
Connection pool e origini dati
nella Documentazione di PostgreSQL
Aggiorna la versione Aurora PostgreSQL
Se la versione attuale di Aurora PostgreSQL è inferiore a 12, esegui l'aggiornamento alla versione 12 o superiore. Le versioni 12 e 13 di PostgreSQL hanno un meccanismo di partizione migliorato. Per ulteriori informazioni sui miglioramenti nella versioni 12, consulta PostgreSQL 12 Release Notes
