LWLock:contenuto_buffer () 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 el versioni di Aurora PostgreSQL.

Context

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 (LWLocks) 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 mantengono i blocchi possono mantenerli più a lungo mentre eseguono operazioni su disco. I/O

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

• Riduzione dell'utilizzo di vincoli di chiave esterna

• Rimuovere gli indici inutilizzati

• Rimuovi gli indici duplicati

• Elimina o REINDICIZZA gli indici non validi

• Utilizza indici parziali

• Rimuovi il bloat della tabella e dell'indice

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 DB Amazon Aurora.

Monitora la BufferCacheHitRatio metrica, che misura la percentuale di richieste servite dalla buffer cache di un'istanza DB nel cluster di database. Questa metrica fornisce informazioni sulla quantità di dati forniti dalla memoria. Un rapporto di successo elevato indica che l'istanza DB dispone di memoria sufficiente per il set di dati di lavoro, mentre un rapporto basso indica che le query accedono spesso ai dati dallo storage.

I risultati di lettura della cache per tabella e risultati di lettura della cache per indice nella sezione Impostazioni di memoria del rapporto PG Collector possono fornire informazioni sul rapporto di accessi alla cache delle tabelle e degli indici.

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 rapporto PG Collector può fornire informazioni sugli indici inutilizzati nel database.

Rimuovi gli indici duplicati

Identifica gli indici duplicati e rimuovili.

La sezione sugli indici duplicati del rapporto PG Collector può fornire informazioni sugli indici duplicati nel database.

Elimina o REINDICIZZA 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 Indici non validi del rapporto PG Collector può fornire informazioni sugli indici non validi nel database.

Utilizza 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 costruito su un sottoinsieme di una tabella, con il sottoinsieme definito da un'espressione condizionale. Come dettagliato nella documentazione sull'indice parziale, gli indici parziali possono ridurre il sovraccarico di gestione degli indici, poiché PostgreSQL non deve aggiornare l'indice in tutti i casi.

Rimuovi il bloat della tabella e dell'indice

Un eccessivo ingrossamento di tabelle e indici può influire negativamente sulle prestazioni del database. Le tabelle e gli indici gonfiati aumentano 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 il gonfiore, fare riferimento a. Diagnosi delle dimensioni della tabella e dell'indice Inoltre, la sezione Fragmentation (Bloat) del report PG Collector può fornire informazioni sull'ingrossamento di tabelle e indici.

Per risolvere il problema del gonfiamento delle tabelle e degli indici, sono disponibili alcune opzioni:

VACUUM FULL

VACUUM FULLcrea una nuova copia della tabella, copiando solo le tuple live, quindi sostituisce la vecchia tabella con quella nuova tenendo premuto un lucchetto. ACCESS EXCLUSIVE Ciò impedisce qualsiasi lettura o scrittura sulla tabella, che può causare un'interruzione. Inoltre, ci VACUUM FULL vorrà più tempo se la tabella è grande.

pg_repack

pg_repackÈ utile in situazioni in cui VACUUM FULL potrebbe non essere adatto. Crea una nuova tabella che contiene i dati della tabella gonfia, 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 usarepg_repack, vedi Rimuovere bloat con pg_repack e pg_repack.

REINDEX

Il comando può essere utilizzato per risolvere il problema del bloat dell'indice. REINDEX REINDEXscrive una nuova versione dell'indice senza le pagine morte o le pagine vuote o quasi vuote, riducendo così il consumo di spazio dell'indice. Per informazioni dettagliate sul REINDEXcomando, consultate 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 future esagerazioni. Per ulteriori informazioni, consulta la documentazione su. Vacuuming and analyzing tables automatically