LWLock:BufferIO (IPC:BufferIO) - Amazon Relational Database Service

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:BufferIO (IPC:BufferIO)

L'evento LWLock:BufferIO si verifica quando RDS per PostgreSQL è in attesa che altri processi finiscano le operazioni di input/output (I/O) quando si tenta contemporaneamente di accedere a una pagina. Il suo scopo è quello di leggere la stessa pagina nel buffer condiviso.

Versioni di motori pertinenti

Queste informazioni relative all'evento di attesa sono pertinenti per tutte le versioni di RDS per PostgreSQL. Per RDS per PostgreSQL 12 e versioni precedenti questo evento di attesa è denominato lwlock:buffer_io mentre in RDS per PostgreSQL versione 13 è denominato lwlock:bufferio. In RDS per PostgreSQL versione 14 l'evento di attesa BufferIO è stato spostato da LWLock al tipo di evento di attesa IPC (IPC:BufferIO).

Context

Ogni buffer condiviso ha un blocco I/O associato all’evento di attesa LWLock:BufferIO, ogni volta che un blocco (o una pagina) deve essere recuperato all'esterno del buffer pool condiviso.

Questo blocco viene utilizzato per gestire più sessioni che richiedono tutte l'accesso allo stesso blocco. Questo blocco deve essere letto dall'esterno del buffer pool condiviso, definito dal parametro shared_buffers.

Non appena la pagina viene letta all'interno del buffer pool condiviso, il blocco LWLock:BufferIO viene rilasciato.

Nota

L'evento di attesa LWLock:BufferIO precede l’evento di attesa IO: DataFileRead. L’evento di attesa IO:DataFileRead si verifica mentre i dati vengono letti dallo storage.

Per ulteriori informazioni sui blocchi leggeri, consultaPanoramica dei blocchi.

Cause

Le cause comuni della comparsa dell'evento LWLock:BufferIO che appare nelle prime attese includono:

  • Più backend o connessioni che tentano di accedere alla stessa pagina in attesa di un'operazione di I/O

  • Il rapporto tra le dimensioni del buffer pool condiviso (definito dal parametro shared_buffers) e il numero di buffer necessari per il carico di lavoro corrente

  • La dimensione del buffer pool condiviso non è ben bilanciata con il numero di pagine sfrattate da altre operazioni

  • Indici grandi o gonfi che richiedono al motore di leggere più pagine del necessario nel buffer pool condiviso

  • Mancanza di indici che costringe il motore DB a leggere più pagine dalle tabelle del necessario

  • Checkpoint che si verificano troppo frequentemente o hanno bisogno di scaricare troppe pagine modificate

  • Picchi improvvisi per le connessioni al database che tentano di eseguire operazioni sulla stessa pagina

Operazioni

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

  • Osservare i parametri di Amazon CloudWatch per la correlazione tra forti diminuzioni degli eventi di attesa BufferCacheHitRatio e LWLock:BufferIO. Questo effetto può significare che hai una piccola impostazione dei buffer condivisi. Potrebbe essere necessario aumentarlo o scalare la classe di istanza DB. È possibile dividere il carico di lavoro in più nodi di lettore.

  • Ottimizza max_wal_size e checkpoint_timeout in base al tempo di picco del carico di lavoro se vedi LWLock:BufferIO in coincidenza con cali dei parametri BufferCacheHitRatio Quindi identifica quale query potrebbe causarla.

  • Verifica se hai indici inutilizzati, quindi rimuovili.

  • Utilizzare tabelle partizionate (che hanno anche indici partizionati). Ciò aiuta a mantenere basso il riordino dell'indice e ne riduce l'impatto.

  • Evitare di indicizzare inutilmente le colonne.

  • Evita improvvisi picchi di connessione al database utilizzando un connection pool.

  • Limitare il numero massimo di connessioni al database come best practice.