LWLock:MultiXact - Amazon Aurora
Versions de moteur prises en chargeContexteCauses probables de l'allongement des temps d'attenteActions

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.

  • LWLock:MultiXactMemberBuffer— Un processus attend des E/S sur un tampon simple 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 utilisé le moins récemment (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 sont prises en charge pour 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 :

  • 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 relationnels objets (ORMs) et couches d'abstraction disposent d'options de configuration permettant d'encapsuler 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'autosaveoption du SQL JDBC pilote Postgre en est un exemple. Pour plus d'informations, consultez pg JDBC dans la SQL JDBC documentation de Postgre. Un autre exemple est le SQL ODBC pilote Postgre et son protocol option. Pour plus d'informations, consultez les options de ODBC configuration psql dans la documentation du SQL ODBC pilote Postgre.

  • Sous-transactions à partir de SQL EXCEPTION clauses PL/pG — Chaque EXCEPTION clause que vous écrivez dans vos SQL fonctions ou procédures PL/pG 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 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 provenant du stockage signifient que les SQL requêtes 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.

  • VACUUMFREEZEUtilisez-le sur la table ou la partition de table concernée pour résoudre le problème immédiatement. Pour de plus amples informations, veuillez consulter VACUUM.

  • Utilisez la clause VACUUM (FREEZE, INDEX _ CLEANUPFALSE) pour effectuer un vide 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, les multixacts VACUUM finiront par supprimer, et leurs valeurs multixact les plus anciennes seront avancées. Pour plus d'informations, consultez Multixacts et Wraparound. Pour limiter au maximum les événements LWLock : MultiXact wait, vous devez les exécuter VACUUM aussi souvent que nécessaire. Pour ce faire, assurez-vous que le cluster VACUUM de SQL base de données Aurora Postgre est configuré de manière optimale.

Si l'utilisation 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 exemplepg_cron, pour effectuer l'opération VACUUM au lieu de régler l'autovacuum au niveau de l'instance.

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 :

  • multixact_offsets_cache_sizejusqu'à 128

  • multixact_members_cache_sizejusqu'à 256

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.

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