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 d’attente LWLock:MultiXactMemberBuffer, LWLock:MultiXactOffsetBuffer, LWLock:MultiXactMemberSLRU et LWLock:MultiXactOffsetSLRU indiquent qu’une session attend de récupérer une liste de transactions qui modifient 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 d’identifiants de transaction (XID) qui modifient la même ligne de table. Lorsqu’une transaction unique fait référence à une ligne dans une table, l’ID de la transaction est stocké dans la ligne d’en-tête de la table. Lorsque plusieurs transactions font référence à la même ligne dans une table, la liste des ID de transaction 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’augmentation du nombre d’événements d’attente

Les trois causes courantes de l’utilisation de multixact sont les suivantes :

Lorsqu’une ligne donnée est incluse dans une opération à transactions multiples, le traitement de la ligne nécessite de récupérer les ID des transactions dans les listings multixact. 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 actions peuvent contribuer à réduire immédiatement les temps d’attente. Cependant, d’autres peuvent nécessiter des recherches supplémentaires et des corrections pour mettre à l’échelle votre charge de travail.

Procéder au gel du processus vacuum sur les tables comportant cet événement d’attente

Si cet événement d’attente connaît un pic soudain et affecte votre environnement de production, vous pouvez utiliser l’une des méthodes temporaires suivantes pour en réduire le nombre.

Augmenter la fréquence d’autovacuum sur les tables comportant cet événement d’attente

Après avoir analysé 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 bouclage. Pour réduire au minimum le nombre d’événements d’attente LWLock:MultiXact, vous devez exécuter la fonction VACUUM aussi souvent que nécessaire. Pour ce faire, assurez-vous que la fonction VACUUM de votre cluster de bases de données Aurora PostgreSQL est configurée 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’événement d’attente, nous vous recommandons d’utiliser un planificateur, tel que pg_cron, pour exécuter le VACUUM au lieu de régler l’autovacuum au niveau de l’instance.

Pour que l’autovacuum ait lieu 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 de multixact 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 ses instances 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. Redémarrez l’instance d’enregistreur pour que la modification des paramètres prenne effet.

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

Réduire les transactions de longue durée

Les transactions de longue durée font que le vacuum conserve les informations de la transaction jusqu’à ce qu’elle soit validée ou jusqu’à ce que la transaction en lecture seule soit fermée. Nous vous recommandons de surveiller et de gérer de manière proactive les transactions de longue durée. Pour plus d’informations, consultez 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 l’utilisation des transactions de longue durée.

Actions à long terme

Examinez votre charge de travail pour identifier la cause des débordements de multixact. Vous devez résoudre le problème afin de pouvoir mettre à l’échelle votre charge de travail et de réduire l’événement d’attente.