synch/mutex/innodb/temp_pool_manager_mutex - Amazon Aurora
Versions de moteur prises en chargeContexteCauses probables de l’augmentation du nombre d’événements 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.

synch/mutex/innodb/temp_pool_manager_mutex

L'événement synch/mutex/innodb/temp_pool_manager_mutex d'attente se produit lorsqu'une session attend d'acquérir un mutex pour gérer le pool de tablespaces temporaires de session.

Versions de moteur prises en charge

Ces informations relatives aux événements d’attente sont prises en charge pour les versions de moteur suivantes :

  • Aurora MySQL version 3

Contexte

Aurora MySQL version 3.x et versions ultérieures permet temp_pool_manager_mutex de contrôler plusieurs sessions accédant simultanément au pool d'espaces de table temporaires. Aurora MySQL gère le stockage via un volume de cluster Aurora pour les données persistantes et le stockage local pour les fichiers temporaires. Un tablespace temporaire est nécessaire lorsqu'une session crée une table temporaire sur le volume du cluster Aurora.

Lorsqu'une session demande pour la première fois un tablespace temporaire, MySQL alloue des tablespaces temporaires de session depuis le pool partagé. Une session peut contenir jusqu'à 2 tablespaces temporaires à la fois pour les types de tables suivants :

  • Tables temporaires créées par l'utilisateur

  • Tables temporaires internes générées par l'optimiseur

Le TempTable moteur par défaut utilise le mécanisme de débordement suivant pour gérer les tables temporaires :

  • Stocke les tables dans la RAM jusqu'à la temptable_max_ramlimite.

  • Se déplace vers les fichiers mappés en mémoire sur le stockage local lorsque la RAM est pleine.

  • Utilise le volume de cluster partagé lorsque les fichiers mappés en mémoire atteignent leur limite. temptable_max_mmap

Lorsque les tables temporaires dépassent à la fois les limites de RAM et de stockage local, MySQL les gère à l'aide d'un espace disque logique.

Lorsqu'une session nécessite une table temporaire sur disque, MySQL :

  • Recherche les INACTIVE tablespaces disponibles dans le pool à réutiliser.

  • Crée 10 nouveaux tablespaces s'il n'en existe aucunINACTIVE.

Lorsqu'une session se déconnecte, MySQL :

  • Tronque les tablespaces temporaires de la session.

  • Les marque comme INACTIFS dans le pool en vue de leur réutilisation.

  • Maintient la taille actuelle du pool jusqu'au redémarrage du serveur.

  • Revient à la taille du pool par défaut (10 tablespaces) après le redémarrage.

Causes probables de l’augmentation du nombre d’événements d’attente

Situations courantes à l'origine de cet événement d'attente :

  • Sessions simultanées créant des tables temporaires internes sur le volume du cluster.

  • Sessions simultanées créant des tables temporaires utilisateur sur le volume du cluster.

  • Fin soudaine de sessions utilisant des tablespaces actifs.

  • Expansion du pool de tablespaces lors de lourdes charges d'écriture.

  • Accès aux requêtes simultanées INFORMATION_SCHEMA.

Actions

Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.

Surveillez et optimisez l'utilisation des tables temporaires

Pour surveiller et optimiser l'utilisation des tables temporaires, appliquez l'une des méthodes suivantes :

  • Consultez le Created_tmp_disk_tables compteur dans Performance Insights pour suivre la création de tables temporaires sur disque dans votre cluster Aurora.

  • Exécutez cette commande dans votre base de données pour surveiller directement la création de tables temporaires :mysql> show status like '%created_tmp_disk%'.

Note

Le comportement des tables temporaires diffère entre les nœuds de lecture et d'écriture Aurora MySQL. Pour de plus amples informations, veuillez consulter Nouveau comportement de table temporaire dans Aurora MySQL version 3.

Après avoir identifié les requêtes créant des tables temporaires, suivez les étapes d'optimisation suivantes :

  • EXPLAINÀ utiliser pour examiner les plans d'exécution des requêtes et identifier où et pourquoi les tables temporaires sont créées.

  • Modifiez les requêtes pour réduire l'utilisation des tables temporaires dans la mesure du possible.

Si l'optimisation des requêtes ne résout pas à elle seule les problèmes de performances, pensez à ajuster les paramètres de configuration suivants :

  • temptable_max_ram- Contrôle l'utilisation maximale de la RAM pour les tables temporaires.

  • temptable_max_mmap- Définit la limite pour le stockage de fichiers mappé en mémoire.

  • tmp_table_size- S'applique lorsqu'aurora_tmptable_enable_per_table_limitil est activé (désactivé par défaut).

Important

Notez que certaines conditions de requête nécessiteront toujours des tables temporaires sur disque, quels que soient les paramètres de configuration. Pour plus d'informations sur le moteur de TempTable stockage, consultez Utiliser le moteur TempTable de stockage sur Amazon RDS for MySQL et Amazon Aurora MySQL.

Révision des requêtes à l'aide de INFORMATION_SCHEMA

Lorsque vous interrogez INFORMATION_SCHEMA des tables, MySQL crée des tables temporaires InnoDB sur le volume du cluster. Chaque session a besoin d'un tablespace temporaire pour ces tables, ce qui peut entraîner des problèmes de performances en cas d'accès simultané élevé.

Pour améliorer les performances :

  • À utiliser PERFORMANCE_SCHEMA au lieu de INFORMATION_SCHEMA là où c'est possible.

  • Si vous devez en utiliserINFORMATION_SCHEMA, réduisez la fréquence à laquelle vous exécutez ces requêtes.

Augmenter le paramètre innodb_sync_array_size

Le innodb_sync_array_size paramètre contrôle la taille du tableau d' mutex/lock attente dans MySQL. La valeur par défaut de 1 fonctionne pour les charges de travail générales, mais son augmentation peut réduire la contention des threads en cas de forte simultanéité.

Lorsque votre charge de travail affiche un nombre croissant de threads en attente :

  • Surveillez le nombre de threads en attente dans votre charge de travail.

  • Définissez un nombre innodb_sync_array_size égal ou supérieur au nombre de vCPU de votre instance pour diviser la structure de coordination des threads et réduire les conflits.

Note

Pour déterminer le nombre de v CPUs disponibles sur votre instance RDS, consultez les spécifications des vCPU dans les types d'instances Amazon RDS.

Implémenter un groupe de connexions

MySQL attribue un tablespace dédié à chaque session qui crée une table temporaire. Ce tablespace reste actif jusqu'à la fin de la connexion à la base de données. Pour gérer vos ressources de manière plus efficace :

  • Implémentez le regroupement de connexions pour limiter le nombre de tablespaces temporaires actifs.

  • Réutilisez les connexions existantes au lieu d'en créer de nouvelles pour chaque opération.