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?

Risoluzione

Con un'istanza Amazon RDS per PostgreSQL inattiva, potresti notare un picco nel parametro Write Latency di Amazon CloudWatch ogni cinque minuti. Ciò è correlato a un picco nella metrica Enhanced Monitoring Write Total a circa 64 MB dopo l'aggiornamento alla versione 11 o successiva di PostgreSQL. Il valore del parametro wal_segment_size diventa 64 MB dopo l'aggiornamento. Questi picchi potrebbero non essere evidenti con la versione 10 o precedente perché il valore di wal_segment_size è 16 MB. Per ulteriori informazioni, consulta l'aggiornamento del 7 settembre 2018 in Amazon RDS - Cronologia documenti.

La configurazione di archive_timeout in Amazon RDS per PostgreSQL è impostata su 5 minuti. Con questa impostazione, il processo di archiviazione copia i segmenti Write-Ahead Logging (WAL) da archiviare su 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, pertanto potrebbe essere visibilmente dominante nei grafici di CloudWatch. Tuttavia, questo schema potrebbe non essere visibile in un sistema occupato. Ad esempio, supponiamo di eseguire il seguente carico di lavoro per 30 minuti su un'istanza db.t3.small. Questo esempio simula un sistema occupato su un'istanza RDS per 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 si vedono picchi nella metrica CloudWatch Write Latency.

Ma supponiamo di avere i seguenti casi d'uso:

• Hai una richiesta di I/O che richiede 10 millisecondi per essere completata e altre nove richieste di I/O che richiedono 1 millisecondo ciascuna per essere completate. 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 che richiede 10 millisecondi per essere completata e non hai 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 che richiede 10 millisecondi per essere completata. Tuttavia, quando si calcola la latenza media, la richiesta lenta si distingue. Questo perché il secondo caso d'uso ha un minor numero di richieste di I/O che vengono eseguite insieme alla richiesta lenta. Se un sistema inattivo ha una richiesta di I/O lenta a causa dell'elevata dimensione del blocco, la latenza viene calcolata solo in base a questa richiesta. In un sistema occupato con più richieste di I/O, prevalentemente con blocchi di dimensioni inferiori, la latenza media viene calcolata in base a tutte queste richieste.

In questi casi, potresti riscontrare un picco di latenza di scrittura ogni cinque minuti in un sistema Amazon RDS per PostgreSQL inattivo. Se l'istanza del database esegue un carico di lavoro intenso, è possibile che questi picchi non vengano visualizzati.

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

Esegui il seguente comando su crontab. Il comando crea un file da 64 MB con una dimensione del blocco di 64 MB ogni cinque minuti nella prima istanza di 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:**Sostituisci big_file.txt nel comando con il nome del tuo file.

Inoltre, esegui il seguente comando su crontab. Il comando crea 100 file ciascuno con una dimensione del blocco di 8 KB ogni minuto nella seconda istanza di 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: sostituisci small_file.txt nel comando con il nome del tuo file.

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

Informazioni correlate

Best practice per l'utilizzo di PostgreSQL