Perché vedo picchi di latenza di scrittura ogni cinque minuti dopo aver aggiornato la mia istanza Amazon RDS for PostgreSQL alla versione 11 o ad una maggiore?

Ultimo aggiornamento: 23/09/2021

Ho aggiornato la mia istanza Amazon Relational Database Service (Amazon RDS) che esegue PostgreSQL alla versione 11 o successiva. Perché vedo un picco di latenza di scrittura in Amazon CloudWatch ogni cinque minuti?

Risoluzione

Con un'istanza Amazon Relational Database Service (Amazon RDS) for PostgreSQL inattiva, potresti notare un picco nel parametro Write Latency di Amazon CloudWatch ogni cinque minuti. Questo picco è correlato a un picco nel parametro Write Total di Monitoraggio avanzato a circa 64 MB dopo l'aggiornamento di PostgreSQL alla versione 11 o successiva. Dopo l'aggiornamento, il valore del parametro wal_segment_size diventa 64 MB. Questi picchi potrebbero non essere evidenti con la versione 10 o precedente perché il valore di wal_segment_size è di 16 MB. Per maggiori informazioni, consulta l'aggiornamento del 7 settembre 2018 in Amazon RDS: cronologia documenti.

La configurazione archive_timeout in RDS for PostgreSQL è impostata su 5 minuti. Questa impostazione indica che il processo di archiviazione copia i segmenti Write-Ahead Logging (WAL) da archiviare in Amazon Simple Storage Service (Amazon S3) ogni cinque minuti. In un sistema inattivo, questo processo di copia è in genere l'unica operazione di I/O, quindi potrebbe essere visibilmente dominante nei grafici di CloudWatch. Tuttavia, è possibile che questo modello non venga visualizzato in un sistema occupato. Ad esempio, supponiamo di eseguire il seguente carico di lavoro per 30 minuti su un'istanza db.t3.small per simulare un sistema occupato su un'istanza RDS for PostgreSQL con un volume Amazon Elastic Block Store (Amazon EBS) da 20 GB:

#pgbench --host=$HOST --username=$USER --port=$PORT --protocol=simple  --progress=2  --client=1 --jobs=1 $DB -T 1800
#pgbench --initialize --fillfactor=90 --scale=100  --port=$PORT --host=$HOST --username=$USER $DB

Con questo carico di lavoro, non noterai picchi nel parametro di latenza di scrittura di CloudWatch.

Ma supponiamo di avere i seguenti casi d'uso:

  • Hai una richiesta di I/O il cui completamento richiede 10 millisecondi e altre nove richieste di I/O il cui completamento richiede 1 millisecondo ciascuna. La latenza media di queste richieste viene calcolata come segue:
    Latenza media = (10 + (9 * 1)) / 10 = 1,9 millisecondi
  • Hai una richiesta di I/O il cui completamento richiede 10 millisecondi e non sono disponibili altre richieste di I/O. La latenza media in questo caso viene calcolata come segue:
    Latenza media = 10 / 1 = 10 millisecondi

Entrambi i casi d'uso includono la stessa richiesta di I/O il cui completamento richiede 10 millisecondi. Tuttavia, quando calcoli la latenza media, la richiesta lenta si distingue nel secondo caso d'uso in cui hai meno richieste di I/O in esecuzione insieme alla richiesta lenta. Se un sistema inattivo ha una richiesta di I/O lenta a causa delle dimensioni del blocco elevate, la latenza viene calcolata solo da questa richiesta. In un sistema occupato con più richieste di I/O, la maggior parte con blocchi di dimensioni inferiori, la latenza media viene calcolata da tutte queste richieste.

In questi casi, è possibile che si verificasse un picco di latenza di scrittura ogni cinque minuti in un sistema RDS for PostgreSQL inattivo. Se l'istanza di database esegue un carico di lavoro occupato, è possibile che questi picchi non siano visibili.

Esempio: supponiamo di avere due istanze Amazon Elastic Compute Cloud (Amazon EC2) t2.small, ciascuna con 8 volumi gp2.

Esegui il comando seguente su crontab per creare un file di 64 MB con una dimensione del blocco di 64 MB ogni cinque minuti nella prima istanza Amazon EC2:

*/5 * * * * dd if=/dev/zero of=/tmp/big_file.txt bs=64MB count=1 oflag=dsync ; rm -rf /tmp/big_file.txt

Nota: assicurati di sostituire big_file.txt nel comando con il nome del file.

Inoltre, esegui il comando seguente su crontab per creare 100 file ciascuno con una dimensione del blocco di 8 KB ogni minuto nella seconda istanza Amazon EC2:

* * * * * for i in {1..100} ; do dd if=/dev/zero of=/tmp/small_file.txt bs=8k count=100 oflag=dsync ; rm -rf /tmp/small_file.txt ; done

Nota: assicurati di sostituire small_file.txt nel comando con il nome del file.

Potresti notare che la seconda istanza EC2 mostra picchi di latenza di scrittura più elevati in CloudWatch rispetto alla prima istanza EC2.


Questo articolo è stato utile?


Hai bisogno di supporto tecnico o per la fatturazione?