Verrou LW : 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.

• LWLock:MultiXactMemberBuffer : un processus attend des E/S sur un tampon simple le moins récemment utilisé (SLRU) pour un membre MultiXact.

• LWLock:MultiXactMemberSLRU : un processus attend d'accéder au cache simple le moins récemment utilisé (SLRU) pour un membre MultiXact.

• LWLock:MultiXactOffsetBuffer : un processus attend des E/S sur un tampon simple le moins récemment utilisé (SLRU) pour un décalage MultiXact.

• LWLock:MultiXactOffsetSLRU : un processus attend d'accéder au cache simple le moins récemment utilisé (SLRU) pour un décalage MultiXact.

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 du tableau. 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 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'allongement des temps d'attente

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

• Sous-transactions à partir de points de sauvegarde explicites — La création explicite d'un point de sauvegarde dans vos transactions génère de nouvelles transactions pour la même ligne. Par exemple, en utilisant SELECT FOR UPDATE, puis SAVEPOINT, puis UPDATE.

  Certains pilotes, mappeurs objet-relationnel (ORM) et couches d'abstraction ont des options de configuration pour envelopper automatiquement toutes les opérations avec des points de sauvegarde. Cela peut générer de nombreux événements d'attente multixact dans certaines charges de travail. L'option autosave du pilote JDBC de PostgreSQL en est un exemple. Pour plus d'informations, consultez pgJDBC dans la documentation PostgreSQL. Un autre exemple est le pilote ODBC de PostgreSQL et son option protocol. Pour plus d'informations, consultez psqlODBC Configuration Options (Options de configuration de psqlODBC) dans la documentation du pilote ODBC PostgreSQL.

• Sous-transactions issues de clauses PL/pgSQL EXCEPTION — Chaque EXCEPTION clause que vous écrivez dans vos fonctions ou procédures PL/pgSQL crée une clause interne. SAVEPOINT

• Clés étrangères : plusieurs transactions acquièrent un verrou partagé sur l'enregistrement parent.

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 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.

Rubriques

• Procédez à la congélation sous vide sur les tables avec cet événement d'attente
• Augmentez la fréquence d'aspiration automatique sur les tables avec cet événement d'attente
• Augmenter les paramètres de mémoire
• Réduisez les transactions de longue durée
• Actions à long terme

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.

• Utilisez VACUUM FREEZE sur la table ou la partition de table concernée pour résoudre le problème immédiatement. Pour plus d'informations, voir VACUUM.

• Utilisez la clause VACUUM (FREEZE, INDEX_CLEANUP FALSE) pour effectuer un aspirateur rapide en omettant les index. Pour plus d'informations, voir Passer l'aspirateur sur une table le plus rapidement possible.

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 limiter au maximum le nombre d'é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 définir les paramètres suivants au niveau du cluster afin que toutes les instances de votre cluster restent cohérentes. Cela permet de réduire les temps d'attente liés à votre charge de travail. Nous vous recommandons de ne pas définir ces valeurs à un niveau trop élevé pour ne pas manquer de mémoire.

• multixact_offsets_cache_sizejusqu'à 128

• multixact_members_cache_sizejusqu'à 256

Vous devez redémarrer l'instance pour que la modification des paramètres soit prise en compte. Avec ces paramètres, vous pouvez utiliser une plus grande partie de la RAM de l'instance pour stocker la structure multixact en mémoire avant de la transférer sur le disque.

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 plus d'informations, voir La base de données est inactive depuis longtemps lors d'une connexion transactionnelle. 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.

• Vous devez analyser le DDL (langage de définition des données) utilisé pour créer vos tables. Assurez-vous que les structures et les index des tables sont bien conçus.

• Lorsque les tables concernées possèdent des clés étrangères, déterminez si elles sont nécessaires ou s'il existe un autre moyen de renforcer l'intégrité référentielle.

• Lorsqu'une table contient de grands index inutilisés, Autovacuum peut ne pas être adapté à votre charge de travail et empêcher son exécution. Pour éviter cela, vérifiez s'il n'y a pas d'index inutilisés et supprimez-les complètement. Pour plus d'informations, consultez la section Gestion de l'autovacuum avec de grands index.

• Réduisez l'utilisation de points de sauvegarde dans vos transactions.