IO:WALWrite - 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à.

IO:WALWrite

Versioni del motore supportate

Queste informazioni relative all'evento di attesa sono supportate per tutte le versioni di RDS per PostgreSQL 10 e successive.

Context

L'attività nel database che genera dati WAL riempie prima i buffer WAL e poi scrive su disco, in modo asincrono. L'evento di attesa IO:WALWrite viene generato quando la sessione SQL è in attesa del completamento della scrittura dei dati WAL su disco in modo da poter rilasciare la chiamata COMMIT della transazione.

Probabili cause di aumento delle attese

Se questo evento di attesa si verifica spesso, è necessario esaminare il carico di lavoro e il tipo di aggiornamenti che il carico di lavoro esegue e la loro frequenza. In particolare, cerca i seguenti tipi di attività.

Attività DML intensa

La modifica dei dati nelle tabelle del database non avviene istantaneamente. Un inserimento in una tabella potrebbe dover attendere l'inserimento o l'aggiornamento della stessa tabella di un altro client. Le istruzioni DML (Data Manipulation Language) per la modifica dei valori dei dati (INSERT, UPDATE, DELETE, COMMIT, ROLLBACK TRANSACTION) possono causare conflitti che fanno sì che il file WAL sia in attesa dello svuotamento dei buffer. Questa situazione è illustrata nelle seguenti metriche di Approfondimenti sulle prestazioni di Amazon RDS che indicano un'attività DML intensa.

  • tup_inserted

  • tup_updated

  • tup_deleted

  • xact_rollback

  • xact_commit

Per ulteriori informazioni su questi parametri, consulta Contatori Performance Insights per Amazon RDS for Postgre SQL.

Attività di punti di controllo frequenti

I punti di controllo frequenti contribuiscono a una maggiore dimensione del WAL. In RDS per PostgreSQL, le scritture di pagina intera sono sempre "attive". Le scritture di pagina intera aiutano a proteggersi dalla perdita di dati. Tuttavia, quando i punti di controllo si verificano troppo spesso, il sistema può presentare problemi generali di prestazioni. Ciò si verifica in particolare nei sistemi con un'attività DML intensa. In alcuni casi, potresti trovare messaggi di errore nel postgresql.log in cui si afferma che i punti di controllo si verificano troppo spesso.

Quando si ottimizzano i punti di controllo, si consiglia di bilanciare attentamente le prestazioni con il tempo previsto necessario per il ripristino in caso di arresto anomalo.

Azioni

Per ridurre il numero degli eventi di attesa, ti consigliamo di eseguire le seguenti azioni.

Riduzione del numero di commit

Per ridurre il numero di commit, puoi combinare le istruzioni in blocchi di transazione. Usa Approfondimenti sulle prestazioni di Amazon RDS per esaminare il tipo di query eseguite. È inoltre possibile spostare le operazioni di manutenzione di grandi dimensioni nelle ore non di punta. Ad esempio, crea gli indici o utilizza le operazioni pg_repack durante le ore non di produzione.

Monitoraggio dei punti di controllo

È possibile monitorare due parametri per verificare la frequenza con cui l'istanza database RDS per PostgreSQL scrive nel file WAL per i punti di controllo.

  • log_checkpoints - Questo parametro è impostato su "on" (attivo) per impostazione predefinita. Fa sì che venga inviato un messaggio al log di PostgreSQL per ogni punto di controllo. Questi messaggi di log includono il numero di buffer scritti, il tempo impiegato per scriverli e il numero di file WAL aggiunti, rimossi o riciclati per il punto di controllo specificato.

    Per ulteriori informazioni su questo parametro, consulta Error Reporting and Logging (Creazione di report e log degli errori) nella documentazione di PostgreSQL.

  • checkpoint_warning - Questo parametro imposta un valore di soglia (in secondi) per la frequenza dei punti di controllo al di sopra del quale viene generato un avviso. Per impostazione predefinita, questo parametro non è impostato in RDS per PostgreSQL. È possibile impostare il valore di questo parametro per ricevere un avviso quando le modifiche al database nell'istanza database RDS per PostgreSQL vengono scritte a una velocità per la quale i file WAL non sono di dimensioni idonee per la gestione. Ad esempio, supponi di impostare questo parametro su 30. Se l'istanza RDS per PostgreSQL deve scrivere le modifiche con una frequenza maggiore rispetto a ogni 30 secondi, nel log di PostgreSQL  viene inviato un avviso indicante che i checkpoint si verificano con una frequenza eccessiva. Questo può indicare che il valore max_wal_size deve essere aumentato.

    Per ulteriori informazioni consulta Write Ahead Log nella documentazione di PostgreSQL.

Aumento dell'I/O

Questo tipo di evento di attesa di input/output (I/O) può essere risolto aumentando le operazioni di input/output al secondo (IOPS) per fornire un I/O più rapido. L'aumento dell'I/O è preferibile a quello della CPU, poiché l'aumento della CPU può comportare ancora più conflitti in termini di I/O in quanto può gestire più lavoro e quindi peggiorare ulteriormente il collo di bottiglia dell'I/O. Come regola generale, ti consigliamo di ottimizzare il carico di lavoro prima di eseguire operazioni di scalabilità.

Volume di registro dedicato (DLV)

Puoi utilizzare un volume di log dedicato (DLV) per un'istanza database che usa l'archiviazione della capacità di IOPS allocata tramite la console Amazon RDS, la AWS CLI o l'API Amazon RDS. Un DLV sposta i log delle transazioni del database PostgreSQL in un volume di archiviazione separato dal volume contenente le tabelle del database. Per ulteriori informazioni, consulta Volume di registro dedicato (DLV).