¿Por qué veo picos de latencia de escritura cada cinco minutos después de actualizar mi instancia de Amazon RDS for PostgreSQL a la versión 11 o posterior?

Resolución

Con una instancia inactiva de Amazon Relational Database Service (Amazon RDS) para PostgreSQL, es posible que observe un aumento en la latencia de escritura de la métrica de Amazon CloudWatch cada cinco minutos. Este pico se correlaciona con un aumento en la métrica de monitoreo mejorada Write Total de aproximadamente 64 MB después de actualizar a PostgreSQL versión 11 o posterior. El valor del parámetro wal_segment_size se convierte en 64 MB después de la actualización. Es posible que estos picos no se noten con la versión 10 o anteriores porque el valor de wal_segment_size es de 16 MB. Para obtener más información, consulte la actualización del 7 de septiembre de 2018 en el historial de documentos de Amazon RDS.

La configuración archive_timeout de RDS para PostgreSQL está establecida en 5 minutos. Esta configuración significa que el proceso de archivado copia los segmentos Write-Ahead Logging (WAL) que se archivan en Amazon Simple Storage Service (Amazon S3) cada cinco minutos. En un sistema inactivo, este proceso de copia suele ser la única operación de E/S, por lo que esta operación podría ser visiblemente dominante en los gráficos de CloudWatch. Sin embargo, es posible que no vea este patrón en un sistema ocupado. Por ejemplo, supongamos que ejecuta la siguiente carga de trabajo durante 30 minutos en una instancia db.t3.small para simular un sistema ocupado en una instancia de RDS for PostgreSQL con un volumen de Amazon Elastic Block Store (Amazon EBS) de 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 esta carga de trabajo, no se observan picos en la métrica Latencia de escritura de CloudWatch.

Pero supongamos que tiene los siguientes casos de uso:

• Tiene una solicitud de E/S que tarda 10 milisegundos en completarse y otras nueve solicitudes de E/S que tardan 1 milisegundo en completarse. La latencia media de estas solicitudes se calcula de la siguiente manera:
  Latencia media = (10 + (9 * 1))/10 = 1,9 milisegundos
• Tiene una solicitud de E/S que tarda 10 milisegundos en completarse y no tiene otras solicitudes de E/S. La latencia media en este caso se calcula de la siguiente manera:
  Latencia media = 10/1 = 10 milisegundos

Ambos casos de uso incluyen la misma solicitud de E/S que tarda 10 milisegundos en completarse. Sin embargo, al calcular la latencia media, la solicitud lenta se destaca en el segundo caso de uso en el que se ejecutan menos solicitudes de E/S junto con la solicitud lenta. Si un sistema inactivo tiene una solicitud de E/S lenta debido al gran tamaño de bloque, la latencia se calcula solo a partir de esta solicitud. En un sistema ocupado con varias solicitudes de E/S, la mayoría con tamaños de bloque más pequeños, la latencia media se calcula a partir de todas estas solicitudes.

En estos casos, es posible que vea un pico de latencia de escritura cada cinco minutos en un sistema RDS for PostgreSQL inactivo. Si la instancia de base de datos ejecuta una carga de trabajo ocupada, es posible que no vea estos picos.

Ejemplo: Supongamos que tiene dos instancias t2.small de Amazon Elastic Compute Cloud (Amazon EC2) con 8 volúmenes gp2 cada una.

Ejecute el siguiente comando en crontab para crear un archivo de 64 MB con un tamaño de bloque de 64 MB cada cinco minutos en la primera instancia de 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: Asegúrese de reemplazar big_file.txt en el comando por el nombre de su archivo.

Además, ejecute el siguiente comando en crontab para crear 100 archivos con un tamaño de bloque de 8 KB cada minuto en la segunda instancia de 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: Asegúrese de reemplazar small_file.txt en el comando por el nombre de su archivo.

Es posible que observe que la segunda instancia EC2 muestra picos de latencia de escritura más altos en CloudWatch que en la primera instancia de EC2.

Información relacionada

Prácticas recomendadas para trabajar con PostgreSQL