Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
IO:WALWrite
Rubriques
Versions de moteur prises en charge
Ces informations sur les événements d'attente sont prises en charge pour RDS for PostgreSQL versions 10 et ultérieures.
Contexte
L'activité de la base de données qui génère les données WAL remplit d'abord les tampons WAL, puis écrit sur le disque de manière asynchrone. L'événement d'attente IO:WALWrite est généré quand la session SQL attend la fin de l'écriture des données WAL sur le disque afin de pouvoir libérer l'appel COMMIT de la transaction.
Causes probables de l'allongement des temps d'attente
Si cet événement d'attente se produit souvent, vous devez examiner votre charge de travail, le type des mises à jour effectuées par votre charge de travail et leur fréquence. En particulier, recherchez les types d'activités suivants.
- Activité DML intense
-
La modification des données dans les tables de base de données ne se produit pas instantanément. Une insertion dans une table peut nécessiter l'attente d'une insertion ou d'une mise à jour dans la même table par un autre client. Les instructions du langage de manipulation de données (DML) permettant de modifier les valeurs des données (INSERT, UPDATE, DELETE, COMMIT, ROLLBACK TRANSACTION) peuvent provoquer des conflits qui obligent le fichier WAL à attendre que les tampons soient vidés. Cette situation est capturée dans les métriques Analyse des performances d'Amazon RDS suivantes, qui indiquent une activité DML intense.
tup_insertedtup_updatedtup_deletedxact_rollbackxact_commit
Pour plus d’informations sur ces métriques, consultez Compteurs Performance Insights pour Amazon RDS pour Postgre SQL.
- Activité des points de vérification fréquents
-
Les points de vérification fréquents contribuent à augmenter la taille du fichier WAL. Dans RDS for PostgreSQL, les écritures de pages complètes sont toujours « activées ». Les écritures de pages complètes favorisent la protection contre les pertes de données. Toutefois, lorsque les points de vérification sont trop fréquents, le système peut rencontrer des problèmes de performances globales. Cela est particulièrement vrai sur les systèmes à activité DML intense. Dans certains cas, vous pouvez trouver des messages d'erreur dans votre fichier
postgresql.logindiquant que « les points de vérification se produisent trop fréquemment ».Lors du réglage des points de vérification, nous vous recommandons de bien équilibrer les performances par rapport au temps nécessaire prévu pour récupérer en cas d'arrêt anormal.
Actions
Nous recommandons les actions suivantes pour réduire le nombre de cet événement d'attente.
Rubriques
Réduisez le nombre de validations
Pour réduire le nombre de validations, vous pouvez combiner les instructions en blocs de transactions. Utilisez Analyse des performances d'Amazon RDS pour examiner le type des requêtes en cours d'exécution. Vous pouvez également déplacer les opérations de maintenance importantes à des heures creuses. Par exemple, créez des index ou utilisez les opérations pg_repack en dehors des heures de production.
Surveillance de vos points de vérification
Vous pouvez surveiller deux paramètres pour voir à quelle fréquence votre instance de base de données RDS for PostgreSQL écrit dans le fichier WAL pour les points de vérification.
log_checkpoints– Ce paramètre est « activé » par défaut. Il provoque l'envoi d'un message au journal PostgreSQL pour chaque point de vérification. Ces messages de journal incluent le nombre de tampons écrits, le temps passé à les écrire et le nombre de fichiers WAL ajoutés, supprimés ou recyclés pour le point de vérification donné.Pour plus d'informations sur ce paramètre, consultez Error Reporting and Logging
(Signalisation et journalisation des erreurs) dans la documentation PostgreSQL. checkpoint_warning– Ce paramètre définit une valeur seuil (en secondes) pour la fréquence des points de vérification, au-dessus de laquelle un avertissement est généré. Par défaut, ce paramètre n'est pas défini dans RDS for PostgreSQL. Vous pouvez définir la valeur de ce paramètre pour recevoir un avertissement lorsque les modifications de base de données dans votre instance de base de données RDS for PostgreSQL sont écrites à une vitesse que les fichiers WAL ne sont pas dimensionnés pour gérer. Par exemple, supposons que vous définissiez ce paramètre sur 30. Si votre instance RDS for PostgreSQL doit écrire des modifications plus souvent que toutes les 30 secondes, l'avertissement indiquant que « les points de vérification se produisent trop fréquemment » est envoyé dans le journal PostgreSQL. Cela peut indiquer que votre valeurmax_wal_sizedoit être augmentée.Pour plus d'informations, consultez Write Ahead Log
dans la documentation PostgreSQL.
Augmenter les E/S
Ce type d'événement d'attente d'entrée/sortie (E/S) peut être corrigé en mettant à l'échelle les opérations d'entrée/sortie par seconde (IOPS) afin de fournir plus rapidement les E/S. La mise à l'échelle des E/S est préférable à la mise à l'échelle du processeur, car la mise à l'échelle du processeur peut entraîner encore plus de conflits d'E/S en gérant plus de travail et aggraver ainsi le goulot d'étranglement d'E/S. En règle générale, nous recommandons d'envisager le réglage de votre charge de travail avant d'exécuter des opérations de mise à l'échelle.
Volume de journal dédié (DLV)
Vous pouvez utiliser un volume dédié aux journaux (DLV) pour une instance de base de données qui utilise le stockage IOPS provisionnés (PIOPS) en utilisant la console Amazon RDS, l' AWS CLI ou l'API Amazon RDS. Un DLV déplace les journaux de transactions de base de données PostgreSQL vers un volume de stockage distinct du volume contenant les tables de base de données. Pour plus d'informations, voir Volume de journal dédié (DLV).
