LWLock:buffer_mapping

Questo evento si verifica quando un processo di backend è in attesa di associare un blocco di dati a un buffer nel pool di buffer condiviso.

Nota

Questo evento appare come LWLock:buffer_mapping in Aurora PostgreSQL versione 12 e versioni successive e LWLock:BufferMapping nella versione 13 e successive.

Versioni del motore supportate

Queste informazioni relative all'evento di attesa sono supportate per Aurora PostgreSQL versione 9.6 e successive.

Context

Il pool buffer condiviso è un'area di memoria Aurora PostgreSQL che contiene tutte le pagine che sono o sono state utilizzate dai processi. Quando un processo ha bisogno di una pagina, legge la pagina nel buffer pool condiviso. Il parametro shared_buffers imposta le dimensioni del buffer condiviso e riserva un'area di memoria per memorizzare la tabella e le pagine indice. Se si modifica questo parametro, assicurarsi di riavviare il database. Per ulteriori informazioni, consultare Buffer condivisi.

L’evento di attesa LWLock:buffer_mapping si verifica nei seguenti scenari:

• Un processo ricerca nella tabella buffer una pagina e acquisisce un blocco di mappatura buffer condiviso.

• Un processo carica una pagina nel buffer pool e acquisisce un esclusivo blocco di mappatura del buffer.

• Un processo rimuove una pagina dal pool e acquisisce un blocco esclusivo di mappatura del buffer.

Cause

Quando questo evento appare più del normale, probabilmente indicando un problema di prestazioni, il database sta eseguendo il paging in entrata e in uscita dal buffer pool condiviso. Le cause tipiche sono:

• Query di grandi dimensioni

• Indici e tabelle gonfie

• Scansioni complete della tabella

• Dimensioni del pool condiviso più piccole del set di lavoro

Operazioni

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

Argomenti

• Monitora i parametri relativi al buffer
• Valuta la tua strategia di indicizzazione
• Riduci il numero di buffer che devono essere allocati rapidamente

Monitora i parametri relativi al buffer

Quando LWLock:buffer_mapping aspetta il picco, indaga il rapporto di hit del buffer. È possibile utilizzare questi parametri per comprendere meglio cosa sta accadendo nella cache del buffer. Esamina i seguenti parametri:

BufferCacheHitRatio

Il parametro Amazon CloudWatch misura la percentuale di richieste gestite dalla cache del buffer di un'istanza database nel cluster di database. È possibile che questo parametro diminuisca in anticipo all’evento di attesa LWLock:buffer_mapping.

blks_hit

Questo parametro contatore Performance Insights indica il numero di blocchi recuperati dal buffer pool condiviso. Dopo che appare l’evento di attesa LWLock:buffer_mapping, potresti osservare un picco in blks_hit.

blks_read

Questo parametro del contatore Performance Insights indica il numero di blocchi che richiedevano la lettura di I/O nel buffer pool condiviso. Potresti osservare un picco in blks_read in vista dell’evento di attesa LWLock:buffer_mapping.

Valuta la tua strategia di indicizzazione

Per confermare che la strategia di indicizzazione non sta peggiorando le prestazioni, verifica quanto segue:

Index bloat

Assicurati che il bloat di indice e tabella non porti alla lettura di pagine non necessarie nel buffer condiviso. Se le tabelle contengono righe inutilizzate, considera l'archiviazione dei dati e la rimozione delle righe dalle tabelle. È quindi possibile ricostruire gli indici per le tabelle ridimensionate.

Indici per query utilizzate di frequente

Per determinare se disponi degli indici ottimali, monitora i parametri del motore DB in Performance Insights. Il parametro tup_returned mostra il numero di righe lette. Il parametro tup_fetched mostra il numero di righe restituite al client. Se tup_returned è significativamente più grande di tup_fetched, i dati potrebbero non essere indicizzati correttamente. Inoltre, le statistiche della tabella potrebbero non essere aggiornate.

Riduci il numero di buffer che devono essere allocati rapidamente

Per ridurre gli eventi di attesa LWLock:buffer_mapping, cercare di ridurre il numero di buffer che devono essere allocati rapidamente. Una strategia consiste nell'eseguire operazioni di batch di dimensioni ridotte. Potresti essere in grado di ottenere batch più piccoli partizionando le tabelle.