Pourquoi est-ce que je constate des pics de latence d'écriture toutes les cinq minutes après la mise à niveau de mon instance Amazon RDS for PostgreSQL vers la version 11 ou supérieure ?

Résolution

Avec une instance Amazon RDS for PostgreSQL inactive, vous remarquerez peut-être un pic de latence d'écriture de la métrique Amazon CloudWatch toutes les cinq minutes. Cela correspond à un pic du total d'écriture de la métrique de surveillance améliorée, qui atteint environ 64 Mo après la mise à niveau vers PostgreSQL version 11 ou ultérieure. La valeur du paramètre wal_segment_size passe à 64 Mo après la mise à niveau. Il se peut que ces pics ne soient pas perceptibles avec la version 10 ou antérieure, car la valeur wal_segment_size est de 16 Mo. Pour en savoir plus, consultez la mise à jour du 7 septembre 2018 sur la page Amazon RDS - Historique du document.

La configuration archive_timeout est définie sur cinq minutes dans Amazon RDS for PostgreSQL. Avec ce paramètre, le processus d'archivage copie les segments Write Ahead Logging (WAL) à archiver dans Amazon Simple Storage Service (Amazon S3) toutes les cinq minutes. Dans un système inactif, ce processus de copie est généralement la seule opération d'E/S. Cette opération peut donc être visiblement dominante dans les graphes CloudWatch. Toutefois, il se peut que vous ne remarquiez pas ce schéma dans un système occupé. Imaginons, par exemple, que vous exécutiez la charge de travail suivante pendant 30 minutes sur une instance db.t3.small. Cet exemple simule un système occupé sur une instance RDS for PostgreSQL avec un volume Amazon Elastic Block Store (Amazon EBS) de 20 Go :

#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

Avec cette charge de travail, vous ne constatez pas de pics dans la métrique de latence d'écriture de CloudWatch.

Mais supposons que vous rencontriez les cas d'utilisation suivants :

• Vous avez une demande d'E/S dont le traitement prend 10 millisecondes, et neuf autres demandes d'E/S d'une milliseconde chacune. La latence moyenne de ces demandes est calculée comme suit :
  Latence moyenne = (10 + (9 * 1))/10 = 1,9 milliseconde
• Vous avez une demande d'E/S dont le traitement prend 10 millisecondes, et vous n'avez aucune autre demande d'E/S. Dans ce cas, la latence moyenne est calculée comme suit :
  Latence moyenne = 10 / 1 = 10 millisecondes

Les deux cas d'utilisation incluent la même demande d'E/S dont le traitement prend 10 millisecondes. Cependant, lorsque vous calculez la latence moyenne, la lenteur de la demande ressort davantage. Cela est dû au fait que le second cas d'utilisation comporte moins de demandes d'E/S qui s'exécutent en même temps que la demande lente. Si un système inactif reçoit une demande d'E/S lente en raison de la taille de bloc élevée, la latence est calculée uniquement à partir de cette demande. Dans un système occupé avec plusieurs demandes d'E/S et que la plupart ont des blocs de petite taille, la latence moyenne est calculée à partir de toutes ces demandes.

Dans ces différents cas, vous pouvez constater un pic de latence d'écriture toutes les cinq minutes dans un système Amazon RDS for PostgreSQL inactif. Si votre instance de base de données exécute une importante charge de travail, il se peut que vous ne remarquiez pas ces pics.

Exemple : supposons que vous disposiez de deux instances Amazon Elastic Compute Cloud (Amazon EC2) t2.small contenant chacune huit volumes gp2.

Exécutez la commande suivante sur crontab. La commande crée un fichier de 64 Mo avec une taille de bloc de 64 Mo toutes les cinq minutes dans la première instance Amazon EC2 :

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

Remarque : remplacez big_file.txt par le nom de votre fichier dans la commande.

Exécutez également la commande suivante sur crontab. La commande crée 100 fichiers d'une taille de bloc de 8 Ko chacun toutes les minutes dans la deuxième instance 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

Remarque : remplacez small_file.txt par le nom de votre fichier dans la commande.

Vous remarquerez peut-être que la deuxième instance EC2 affiche des pics de latence d'écriture plus élevés que la première instance EC2 dans CloudWatch.

Informations connexes

Bonnes pratiques d'utilisation de PostgreSQL