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

Resolución

Con una instancia de Amazon RDS para PostgreSQL inactiva, es posible que observe un pico en la métrica Latencia de escritura de Amazon CloudWatch cada cinco minutos. Esto se correlaciona con un aumento en la métrica de monitoreo mejorada Total de escrtiura de aproximadamente 64 MB después de actualizar a PostgreSQL versión 11 o posterior. Tras la actualización, el valor del parámetro wal_segment_size pasa a ser de 64 MB. 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 Historial de revisión de Amazon RDS.

La configuración archive_timeout de Amazon RDS para PostgreSQL está establecida en 5 minutos. Con esta configuración, 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. Este ejemplo simula un sistema ocupado en una instancia de RDS para 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 de 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 ninguna otra solicitud 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, cuando se calcula la latencia media, destaca la solicitud lenta. Esto se debe a que el segundo caso de uso tiene menos solicitudes de E/S que se ejecutan junto con la solicitud lenta. Si un sistema inactivo tiene una solicitud de E/S lenta debido al gran tamaño del bloque, la latencia se calcula únicamente 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 Amazon RDS para 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), cada una con 8 volúmenes gp2.

Al ejecutar el siguiente comando en crontab, se crea 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: Sustituya big_file.txt en el comando por el nombre de su archivo.

Además, ejecute el siguiente comando en crontab para crear 100 archivos, cada uno 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: Sustituya small_file.txt en el comando por el nombre de su archivo.

Puede observar que la segunda instancia de EC2 muestra picos de latencia de escritura más altos en CloudWatch que la primera instancia de EC2.

Información relacionada

Prácticas recomendadas para trabajar con PostgreSQL