

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)
<a name="wait-event.lwlockbufferio"></a>

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.

**Topics**
+ [Versioni di motori pertinenti](#wait-event.lwlockbufferio.context.supported)
+ [Context](#wait-event.lwlockbufferio.context)
+ [Cause](#wait-event.lwlockbufferio.causes)
+ [Azioni](#wait-event.lwlockbufferio.actions)

## Versioni di motori pertinenti
<a name="wait-event.lwlockbufferio.context.supported"></a>

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\$1io 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
<a name="wait-event.lwlockbufferio.context"></a>

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](wait-event.iodatafileread.md). L’evento di attesa `IO:DataFileRead` si verifica mentre i dati vengono letti dallo storage.

Per ulteriori informazioni sui blocchi leggeri, consulta[Panoramica dei blocchi](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).

## Cause
<a name="wait-event.lwlockbufferio.causes"></a>

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

## Azioni
<a name="wait-event.lwlockbufferio.actions"></a>

Consigliamo azioni diverse a seconda delle cause dell'evento di attesa:
+ 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.