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:buffer_content (BufferContent)
L’evento LWLock:buffer_content si verifica quando una sessione è in attesa di accedere in lettura o scrittura a una pagina dati in memoria mentre un’altra sessione ha bloccato la pagina in scrittura. In Aurora PostgreSQL 13 e versioni successive, questo evento di attesa viene chiamato BufferContent.
Versioni del motore supportate
Queste informazioni relative all’evento di attesa sono supportate per tutte le versioni di Aurora PostgreSQL.
Contesto
Per leggere o manipolare i dati, PostgreSQL vi accede tramite buffer di memoria condivisa. Per leggere dal buffer, un processo ottiene un blocco leggero (LWLock) sul contenuto del buffer in modalità condivisa. Per scrivere sul buffer, ottiene quel blocco in modalità esclusiva. I blocchi condivisi consentono ad altri processi di acquisire contemporaneamente blocchi condivisi su quel contenuto. I blocchi esclusivi impediscono ad altri processi di ottenere qualsiasi tipo di blocco.
L’evento LWLock:buffer_content (BufferContent) indica che più processi stanno tentando di ottenere blocchi leggeri sul contenuto di un buffer specifico.
Probabili cause di aumento delle attese
Quando l’evento LWLock:buffer_content (BufferContent) si verifica più del normale, probabilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti.
- Aggiornamenti simultanei aumentati degli stessi dati
-
Potrebbe esserci un aumento del numero di sessioni simultanee con query che inseriscono o aggiornano la stessa tabella. Questa contesa può essere più marcata sulle tabelle con molti indici.
- I dati del carico di lavoro non sono in memoria
-
Quando i dati elaborati dal carico di lavoro attivo non sono in memoria, questi eventi di attesa possono aumentare. Questo effetto è dovuto al fatto che i processi che contengono blocchi possono mantenerli più a lungo mentre eseguono operazioni di I/O su disco.
- Uso eccessivo di vincoli di chiave esterna
-
I vincoli di chiave esterna possono aumentare la quantità di tempo che un processo mantiene su un blocco del contenuto del buffer. Questo effetto è dovuto al fatto che le operazioni di lettura richiedono un blocco del contenuto del buffer condiviso sulla chiave di riferimento mentre quella chiave viene aggiornata.
Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa. Potresti identificare eventi LWLock:buffer_content (BufferContent) utilizzando Amazon RDS Performance Insights o interrogando la vista pg_stat_activity.
Argomenti
Migliora l’efficienza in memoria
Per aumentare la probabilità che i dati del carico di lavoro attivo si trovino in memoria, partizionare tabelle o scalare la classe di istanza. Per informazioni sulle classi di istanza database, consulta Classi di istanze database Amazon Aurora.
Monitorare la metrica BufferCacheHitRatio, che misura la percentuale di richieste gestite dalla cache del buffer di un’istanza database nel cluster di database. Questa metrica fornisce informazioni sulla quantità di dati gestiti dalla memoria. Una percentuale di riscontri elevata indica che l’istanza database dispone di memoria sufficiente per il set di dati di lavoro, mentre una percentuale bassa suggerisce che le query accedono frequentemente ai dati dalla risorsa di archiviazione.
I riscontri di lettura nella cache per tabella e i riscontri di lettura nella cache per indice nella sezione Impostazioni memoria del report PG Collector
Riduzione dell’utilizzo di vincoli di chiave esterna
Indagare sui carichi di lavoro con un numero elevato di eventi di attesa LWLock:buffer_content (BufferContent) per l’utilizzo di vincoli di chiave esterna. Rimuovere i vincoli di chiave esterna non necessari.
Rimuovere gli indici inutilizzati
Per carichi di lavoro con un numero elevato di eventi di attesa LWLock:buffer_content (BufferContent), identificare gli indici inutilizzati e rimuoverli.
La sezione degli indici inutilizzati del report PG Collector
Rimuovere gli indici duplicati
Identificare gli indici duplicati e rimuoverli.
La sezione degli indici duplicati del report PG Collector
Eseguire eliminazione o REINDEX per gli indici non validi
Gli indici non validi si verificano in genere quando si utilizza CREATE INDEX CONCURRENTLY o REINDEX CONCURRENTLY e il comando ha esito negativo o viene interrotto.
Gli indici non validi non possono essere utilizzati per le query, ma verranno comunque aggiornati e occuperanno spazio su disco.
La sezione degli indici non validi del report PG Collector
Utilizzare gli indici parziali
Gli indici parziali possono essere utilizzati per migliorare le prestazioni delle query e ridurre le dimensioni dell’indice. Un indice parziale è un indice creato su un sottoinsieme di una tabella, con il sottoinsieme definito da un’espressione condizionale. Come descritto nella documentazione sugli indici parziali
Rimuovere il bloat di tabelle e indici
Un eccessivo bloat di tabelle e indici può influire negativamente sulle prestazioni del database. Un bloat delle tabelle e degli indici aumenta le dimensioni del set di lavoro attivo, riducendo l’efficienza della memoria. Inoltre, il bloat aumenta i costi di archiviazione e rallenta l’esecuzione delle query. Per diagnosticare un bloat, consulta Diagnosi delle dimensioni della tabella e dell'indice. Inoltre, la sezione Fragmentation (Bloat) del report PG Collector
Per risolvere il problema del bloat di tabelle e indici, sono disponibili alcune opzioni:
- VACUUM FULL
-
VACUUM FULLcrea una nuova copia della tabella, copiando solo le tuple attive, quindi sostituisce la vecchia tabella con quella nuova mantenendo un bloccoACCESS EXCLUSIVE. Ciò impedisce qualsiasi lettura o scrittura sulla tabella, che può causare un’interruzione. Inoltre,VACUUM FULLrichiederà più tempo se la tabella è di grandi dimensioni. - pg_repack
-
pg_repackè utile in situazioni in cuiVACUUM FULLpotrebbe non essere adatto. Crea una nuova tabella che contiene i dati della tabella con bloat, tiene traccia delle modifiche rispetto alla tabella originale e quindi sostituisce la tabella originale con quella nuova. Non blocca la tabella originale per le operazioni di lettura o scrittura durante la creazione della nuova tabella. Per ulteriori informazioni su come utilizzarepg_repack, consulta Rimozione del bloat con pg_repack e pg_repack. - REINDEX
-
Il comando
REINDEXpuò essere utilizzato per risolvere il problema del bloat dell’indice.REINDEXscrive una nuova versione dell’indice senza le pagine inattive o le pagine vuote o quasi vuote, riducendo così il consumo di spazio dell’indice. Per informazioni dettagliate sul comandoREINDEX, consulta la documentazione di REINDEX.
Dopo aver rimosso il bloat dalle tabelle e dagli indici, potrebbe essere necessario aumentare la frequenza dell’autovacuum su tali tabelle. L’implementazione di impostazioni aggressive dell’autovacuum a livello di tabella può aiutare a prevenire il verificarsi di futuri bloat. Per ulteriori informazioni, consulta la documentazione su Vacuuming and analyzing tables
automatically.
