Comment résoudre les pics de latence d'écriture dans mon instance de base de données RDS Amazon ?

Brève description

La métrique Amazon CloudWatch WriteLatency définit le temps moyen nécessaire pour chaque opération d'E/S sur disque. De préférence, la latence d'écriture ne doit pas excéder une milliseconde à un chiffre.

Le pic de latence d'écriture pour votre instance de base de données peut être atteint lorsque vous effectuez les opérations suivantes :

• Créez une sauvegarde Amazon RDS de votre instance de base de données Single-AZ
• Convertissez l’instance RDS Single-AZ en instance Multi-AZ
• Effectuez une restauration à partir d'un instantané de base de données
• Effectuer une restauration ponctuelle de votre instance de base de données
• Créez un nouveau réplica en lecture

Le pic peut également résulter d'IOPS ou d'un goulot d'étranglement du débit dû à une charge de travail conséquente sur la base de données.

Solution

Résolution des pics de latence

1.    Pour la résolution des causes d'une latence en lecture ou en écriture élevée sur votre instance de base de données, consultez les métriques CloudWatch suivantes :

• ReadLatency et WriteLatency
• ReadIOPS and WriteIOPS
• ReadThroughput et WriteThroughput
• DiskQueueDepth
• BurstBalance (pour le stockage GP2)

Supposons que vous remarquiez un ou plusieurs des éléments suivants :

• Des valeurs de latence élevées.
• Un débit et des valeurs IOPS ayant atteint leurs limites maximales.
• Une valeur de DiskQueueDepth élevée.
• Une valeur de BurstBalance faible (pour gp2).

Cela signifie que votre instance RDS est soumise à une charge de travail conséquente et nécessite davantage de ressources. Pour plus d’information, consultez la page comment résoudre les problèmes de latence des volumes Amazon EBS causés par un goulot d'étranglement IOPS dans mon instance Amazon RDS ?

Afin de résoudre les problèmes à l'origine d'un goulot d'étranglement d'IOPS ou de débit, procédez comme suit :

Pour une instance RDS avec SSD à usage général (gp2), vérifiez la classe d'instance de base de données et la capacité de stockage.

Pour une instance RDS avec IOPS provisionnés (io1), vérifiez la classe d'instance de base de données et les IOPS provisionnés définis.

Pour plus d'informations, consultez les classes d'instances de base de données et les instances optimisées pour Amazon EBS.

2.    Si les métriques CloudWatch n'indiquent aucune limitation des ressources, vérifiez alors les E/S en lecture et en écriture, grâce à la Surveillance améliorée.

Les métriques CloudWatch sont enregistrées chaque 60 secondes. Par conséquent, tous les pics ou toutes les baisses peuvent ne pas être enregistré(e)s. Cependant, vous pouvez configurer la granularité de la surveillance améliorée à une seconde au maximum, afin de capturer des données. Tout pic d'utilisation des ressources dans un intervalle de 60 secondes peut être capturé grâce à la surveillance améliorée. Pour plus d’information, consultez Comment savoir si mon volume EBS subit un micro-bursting et comment empêcher cela ?

3.    Si toutes les vérifications précédentes n'indiquent pas la cause du problème, vérifiez les métriques CloudWatch NetworkReceiveThroughput et NetworkTransmitThroughput pour vous assurer que le réseau fonctionne correctement.

Atténuer l'impact du chargement différé

Lorsque vous restaurez une instance de base de données RDS à partir d'un instantané, l'instance de base de données continue le chargement des données en arrière-plan. Ce processus est connu sous le nom de chargement différé.

Le chargement différé peut se produire dans tous les scénarios nécessitant une restauration à partir d'un instantané. Ceci comprend la restauration à un état antérieur spécifique, la conversion d'une instance Single-AZ en instance Multi-AZ, ainsi que la création d'un nouveau réplica en lecture. Si vous essayez d'accéder à des données qui ne sont pas encore chargées, l'instance de base de données téléchargera immédiatement les données souhaitées depuis Amazon Simple Storage Service (Amazon S3). Ensuite, l'instance continuera de charger le reste des données en arrière-plan. Pour en savoir plus, consultez la section Instantanés Amazon EBS. Pour atténuer les effets du chargement différé sur les tables auxquelles vous devez accéder rapidement, vous pouvez effectuer des opérations qui requièrent des analyses de tables complètes, telles que SELECT *. Cela permet à RDS de télécharger toutes les données de table sauvegardées depuis Amazon S3.

Suivez les bonnes pratiques

Lorsque vous êtes confronté à une latence d'écriture élevée dans votre instance de base de données, gardez à l'esprit les bonnes pratiques et solutions de contournement suivantes :

• Assurez-vous qu’une quantité suffisante de ressources sont allouées à votre base de données pour l’exécution des requêtes. Avec RDS, la quantité de ressources allouées est fonction du type d'instance.
• Si ni les métriques CloudWatch ni les métriques Enhanced Monitoring n'indiquent une limitation des ressources, utilisez Performance Insights pour surveiller la charge de travail de la base de données. À l’aide de Performance Insights, vous pouvez identifier les requêtes SQL sous-jacentes qui s'exécutent dans votre base de données lorsque vous rencontrez une latence avec votre application. Vous pouvez utiliser ces informations pour évaluer la charge de votre base de données et déterminer les mesures à prendre. Pour plus d'informations, consultez Surveillance de la charge de la base de données avec Performance Insights sur Amazon RDS.
• Évitez les micro-bursting en modifiant la taille ou le type de volume Amazon EBS en fonction de votre cas d'utilisation.
• Pour optimiser les performances de la base de données, assurez-vous que vos requêtes sont correctement réglées.
• Si vous convertissez votre instance de base de données Single-AZ en instance Multi-AZ, envisagez de le faire en dehors des heures de travail.
• Afin de réduire l'impact du chargement différé après une conversion Multi-AZ, envisagez de procéder de l'une des manières suivantes :

• Effectuez un basculement manuel peu de temps après la conversion en instance Multi-AZ.
• Exécutez un vidage complet ou exécutez uniquement les requêtes requises pour charger toutes les données des tables. Ce processus peut être utile au chargement de données et forcer à pousser les blocs de S3 vers le nouvel hôte. Vous pouvez exécuter la commande pg_prewarm pour les instances Amazon RDS for PostgreSQL.

• Vous pouvez configurer les alarmes Amazon CloudWatch sur les métriques clés RDS nécessaires pour déterminer la cause des pics de latence d'écriture dans vos instances RDS. Examples of these metrics include ReadIOPS, WriteIOPS, ReadThroughput, WriteThroughput, DiskQueueDepth, ReadLatency, et WriteLatency. Vous pouvez utiliser ces alarmes pour vous assurer que l'instance ne ralentit pas.

---

Informations connexes

Bonnes pratiques pour Amazon RDS

Comprendre les performances de débordement par rapport aux performances de base avec Amazon RDS et GP2

Modification d'une instance de base de données pour en faire un déploiement d'instance de base de données Multi-AZ

Tutoriel : Restauration d'une instance de base de données Amazon RDS à partir d'un instantané de base de données