synch/sxlock/innodb/hash_table_locks

L'synch/sxlock/innodb/hash_table_locksévénement se produit lorsque des pages introuvables dans le pool de mémoire tampon doivent être lues depuis le stockage.

Versions de moteur prises en charge

Ces informations relatives aux événements d'attente sont prises en charge dans les versions suivantes :

• Aurora MySQL versions 2 et 3

Contexte

L'événement synch/sxlock/innodb/hash_table_locks indique qu'une charge de travail accède fréquemment à des données qui ne sont pas stockées dans le groupe de mémoires tampons. Cet événement d'attente est associé à des ajouts de nouvelles pages et expulsions d'anciennes données du groupe de mémoires tampons. Les données stockées dans le groupe de mémoires tampons correspondant aux anciennes et nouvelles données doivent être mises en cache pour permettre l'expulsion des anciennes pages et la mise en cache des nouvelles pages. MySQL utilise un algorithme LRU (Last Recently Used) pour expulser les pages du groupe de mémoires tampons. La charge de travail tente d'accéder aux données qui n'ont pas été chargées dans le groupe de mémoires tampons ou aux données qui ont été expulsées de ce dernier.

Cet événement d'attente se produit lorsque la charge de travail doit accéder aux données de fichiers sur disque ou lorsque des blocs sont libérés ou ajoutés à la liste LRU du groupe de mémoires tampons. Ces opérations attendent d'obtenir un verrou partagé exclu (SX-Lock). Ce verrou SX-Lock est utilisé pour la synchronisation sur la table de hachage, qui est une table en mémoire conçue pour améliorer les performances d'accès au groupe de mémoires tampons.

Pour plus d'informations, consultez Buffering and Caching dans la documentation MySQL.

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

Lorsque l'événement d'attente synch/sxlock/innodb/hash_table_locks se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performance, les causes sont généralement les suivantes :

Groupe de mémoires tampons sous-dimensionné

La taille du groupe de mémoires tampons est insuffisante pour conserver en mémoire toutes les pages fréquemment consultées.

Charge de travail importante

La charge de travail entraîne de fréquentes expulsions et le rechargement de pages de données dans le cache de tampon.

Erreurs de lecture des pages

Le groupe de mémoires tampons présente des erreurs de lectures de pages, ce qui peut indiquer une corruption des données.

Actions

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

Rubriques

• Augmentez la taille du groupe de mémoires tampons
• Améliorer les modèles d'accès aux données
• Réduire ou éviter les analyses de table entière
• Rechercher une éventuelle corruption des pages dans les journaux d'erreurs

Augmentez la taille du groupe de mémoires tampons

Assurez-vous que le groupe de mémoires tampons est correctement dimensionné pour la charge de travail. Pour ce faire, vous pouvez vérifier le taux d'accès au cache du groupe de mémoires tampons. En règle générale, si la valeur est inférieure à 95 %, envisagez d'augmenter la taille du groupe de mémoires tampons. Un groupe de mémoires tampons plus important peut conserver les pages fréquemment consultées en mémoire plus longtemps. Pour augmenter la taille du groupe de mémoires tampons, modifiez la valeur du paramètre innodb_buffer_pool_size. La valeur par défaut de ce paramètre dépend de la taille de la classe d'instance de base de données. Pour plus d'informations, consultez Bonnes pratiques relatives à la configuration de base de données Amazon Aurora MySQL.

Améliorer les modèles d'accès aux données

Vérifiez les requêtes affectées par cette attente ainsi que leurs plans d'exécution. Pensez à améliorer les modèles d'accès aux données. Par exemple, si vous utilisez mysqli_result::fetch_array, vous pouvez essayer d'augmenter la taille d'extraction du tableau.

Vous pouvez utiliser Performance Insights pour afficher les requêtes et les sessions susceptibles d'entraîner l'événement d'attente synch/sxlock/innodb/hash_table_locks.

Pour rechercher les requêtes SQL responsables d'une charge élevée

1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

2. Dans le volet de navigation, choisissez Performance Insights.

3. Choisissez une instance de base de données. Le tableau de bord Performance Insights s'affiche pour cette instance de base de données.

4. Dans le graphique Database load (Charge de base de données), choisissez Slice by wait (Tranche par attente).

5. Au bas de la page, choisissez Top SQL (Principaux éléments SQL).

   Le graphique répertorie les requêtes SQL responsables de la charge. Les requêtes situées en haut de la liste sont les plus responsables. Pour résoudre un goulet d'étranglement, concentrez-vous sur ces instructions.

Pour une présentation de la résolution des problèmes à l'aide de Performance Insights, consultez le billet de blog AWS Database Amazon Aurora MySQL Workloads with Performance Insights.

Réduire ou éviter les analyses de table entière

Surveillez votre charge de travail pour voir si elle exécute des analyses de table entière et, si tel est le cas, les réduire ou les éviter. Par exemple, vous pouvez surveiller des variables d'état telles que Handler_read_rnd_next. Pour plus d'informations, consultez Server Status Variables dans la documentation MySQL.

Rechercher une éventuelle corruption des pages dans les journaux d'erreurs

Vous pouvez consulter le journal mysql-error.log afin d'y détecter d'éventuels messages de corruption au moment du problème. Les messages à utiliser pour résoudre le problème se trouvent dans le journal des erreurs. Vous devrez peut-être recréer les objets signalés comme corrompus.