Pourquoi est-ce que je vois 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 ultérieure ?

Date de la dernière mise à jour : 23/09/2021

J'ai mis à niveau mon instance Amazon Relational Database Service (Amazon RDS) exécutant PostgreSQL vers la version 11 ou ultérieure. Pourquoi est-ce que je constate un pic de latence d'écriture dans Amazon CloudWatch toutes les cinq minutes ?

Résolution

Avec une instance Amazon Relational Database Service (Amazon RDS) pour PostgreSQL inactive, vous remarquerez peut-être un pic de latence d'écriture de la métrique Amazon CloudWatch toutes les cinq minutes. Ce pic est en corrélation avec un pic de la métrique de surveillance améliorée Write Total à 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. Ces pics peuvent ne pas être perceptibles avec la version 10 ou antérieure, car la valeur de wal_segment_size est de 16 Mo. Pour plus d'informations, consultez la mise à jour du 7 septembre 2018 dansAmazon RDS – Historique des documents.

Archive_timeout est configuré dans RDS pour PostgreSQL avec une valeur de 5 minutes. Autrement dit, le processus d'archivage copie les segments Write-Ahead Logging (WAL) à archiver sur 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'I/O, laquelle peut être visiblement dominante dans les graphiques CloudWatch. Toutefois, vous pouvez ne pas voir ce schéma dans un système occupé. Par exemple, supposons que vous exécutez l'application suivante pendant 30 minutes sur une instance db.t3.small pour simuler un système occupé sur une instance RDS pour 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 application, vous ne constatez pas de pics dans la mesure de latence d'écriture CloudWatch.

Supposons que vous ayez plutôt les cas d'utilisation suivants :

  • Vous avez une demande I/O qui dure 10 millisecondes et neuf autres qui durent 1 milliseconde chacune. La latence moyenne de ces demandes est calculée comme suit :
    Latence moyenne = (10 + (9* 1))/10 = 1,9 millisecondes
  • Vous avez une seule demande d'I/O qui dure10 millisecondes. Dans ce cas, la latence moyenne est calculée comme suit :
    Latence moyenne = 10/1 = 10 millisecondes

Les deux cas d'utilisation comprennent la même demande I/O qui dure 10 millisecondes. Toutefois, lorsque vous calculez la latence moyenne, la demande lente se distingue dans le deuxième cas d'utilisation où vous avez moins de demandes d'I/O qui s'exécutent en même temps qu'elle. Si un système inactif a une demande d'I/O 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'I/O, la plupart avec des blocs de plus petite taille, la latence moyenne est calculée à partir de toutes ces demandes.

Dans ces cas, vous pouvez voir un pic de latence d'écriture toutes les cinq minutes dans un système RDS pour PostgreSQL inactif. Si votre instance de base de données exécute une application occupée, il se peut que vous ne voyiez pas ces pics.

Exemple : supposons que vous disposez de deux instances Amazon Elastic Compute Cloud (Amazon EC2)t2.small avec chacune 8 volumes gp2.

Exécutez la commande suivante sur crontab pour créer 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 : veillez à remplacerbig_file.txt dans la commande par le nom de votre fichier.

Exécutez également la commande suivante sur crontab pour créer 100 fichiers chacun d'une taille de bloc de 8 Ko 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 : veillez à remplacer small_file.txt dans la commande par le nom de votre fichier.

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


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?