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.

LWLock:MultiXact

Les événements LWLock:MultiXactMemberBufferLWLock:MultiXactOffsetBuffer,LWLock:MultiXactMemberSLRU, et LWLock:MultiXactOffsetSLRU wait indiquent qu'une session attend de récupérer une liste de transactions modifiant la même ligne dans une table donnée.

Versions de moteur prises en charge

Ces informations sur les événements d'attente s'appliquent à toutes les versions d'Aurora PostgreSQL.

Contexte

Un multixact est une structure de données qui stocke une liste de transactions IDs (XIDs) qui modifient la même ligne de table. Lorsqu'une seule transaction fait référence à une ligne d'un tableau, l'ID de transaction est stocké dans la ligne d'en-tête du tableau. Lorsque plusieurs transactions font référence à la même ligne dans une table, la liste des transactions IDs est stockée dans la structure de données multixact. Les événements d'attente multixact indiquent qu'une session est en train de récupérer dans la structure de données la liste des transactions qui font référence à une ligne donnée d'une table.

Causes probables de l'allongement des temps d'attente

Les trois causes les plus fréquentes de l'utilisation de multixact sont les suivantes :

Lorsqu'une ligne donnée est incluse dans une opération de transactions multiples, le traitement de la ligne nécessite IDs de récupérer la transaction dans les multixact listes. Si les recherches ne peuvent pas obtenir le multixact à partir du cache mémoire, la structure de données doit être lue à partir de la couche de stockage Aurora. Ces E/S du stockage signifient que les requêtes SQL peuvent prendre plus de temps. Les pertes de mémoire cache peuvent commencer à se produire en cas d'utilisation intensive due à un grand nombre de transactions multiples. Tous ces facteurs contribuent à l'augmentation de cet événement d'attente.

Actions

Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente. Certaines de ces mesures peuvent contribuer à réduire immédiatement les temps d'attente. Mais d'autres peuvent nécessiter des recherches et des corrections pour augmenter votre charge de travail.

Procédez à la congélation sous vide sur les tables avec cet événement d'attente

Si cet événement d'attente augmente soudainement et affecte votre environnement de production, vous pouvez utiliser l'une des méthodes temporaires suivantes pour en réduire le nombre.

Augmentez la fréquence d'aspiration automatique sur les tables avec cet événement d'attente

Après avoir scanné toutes les tables de toutes les bases de données, VACUUM finira par supprimer les multixacts, et leurs valeurs multixact les plus anciennes seront avancées. Pour plus d'informations, consultez Multixacts et Wraparound. Pour réduire au minimum les événements LWLock : MultiXact wait, vous devez exécuter le VACUUM aussi souvent que nécessaire. Pour ce faire, assurez-vous que le VACUUM de votre cluster de base de données Aurora PostgreSQL est configuré de manière optimale.

Si l'utilisation de VACUUM FREEZE sur la table ou la partition de table concernée résout le problème d'attente, nous vous recommandons d'utiliser un planificateur, par exemple pour exécuter le VACUUM au lieu de régler l'autovacuum au niveau de l'instance. pg_cron

Pour que l'autovacuum se produise plus fréquemment, vous pouvez réduire la valeur du paramètre de stockage autovacuum_multixact_freeze_max_age dans le tableau concerné. Pour plus d'informations, consultez autovacuum_multixact_freeze_max_age.

Augmenter les paramètres de mémoire

Vous pouvez optimiser l'utilisation de la mémoire pour les caches multixact en ajustant les paramètres suivants. Ces paramètres contrôlent la quantité de mémoire réservée à ces caches, ce qui peut contribuer à réduire les temps d'attente multiples dans votre charge de travail. Nous vous recommandons de commencer par les valeurs suivantes :

Vous pouvez définir ces paramètres au niveau du cluster afin que toutes les instances de votre cluster restent cohérentes. Nous vous recommandons de tester et d'ajuster les valeurs en fonction de vos exigences spécifiques en matière de charge de travail et de classe d'instance. Vous devez redémarrer l'instance du rédacteur pour que les modifications des paramètres soient prises en compte.

Les paramètres sont exprimés en termes d'entrées de cache multixact. Chaque entrée de cache utilise 8 KB de la mémoire. Pour calculer la mémoire totale réservée, multipliez la valeur de chaque paramètre par8 KB. Par exemple, si vous définissez un paramètre sur 128, la mémoire réservée totale sera de128 * 8 KB = 1 MB.

Réduisez les transactions de longue durée

Une transaction de longue durée oblige le vide à conserver ses informations jusqu'à ce que la transaction soit validée ou jusqu'à ce que la transaction en lecture seule soit clôturée. Nous vous recommandons de surveiller et de gérer de manière proactive les transactions de longue durée. Pour de plus amples informations, veuillez consulter La base de données a une connexion de longue durée à l'état Transaction inactive. Essayez de modifier votre application pour éviter ou minimiser le recours à des transactions de longue durée.

Actions à long terme

Examinez votre charge de travail pour découvrir la cause des répercussions de Multixact. Vous devez résoudre le problème afin d'augmenter votre charge de travail et de réduire le temps d'attente.