synch/sxlock/innodb/hash_verrous de table

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 My SQL 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. My SQL utilise l'algorithme le moins récemment utilisé (LRU) pour expulser les pages du pool de mémoire tampon. 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 contenues dans des fichiers sur disque ou lorsque des blocs sont libérés ou ajoutés à la LRU liste du pool de mémoire tampon. 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 la section Buffer Pool dans la section Ma SQL documentation.

Causes probables de l'allongement des temps 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 pour la configuration de la SQL base de données Amazon Aurora My.

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 SQL les requêtes responsables d'une charge élevée

1. Connectez-vous à la RDS console Amazon AWS Management Console et ouvrez-la à 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.

   Le graphique répertorie les SQL requêtes responsables du chargement. 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 utile du dépannage à l'aide de Performance Insights, consultez le billet de blog AWS consacré à la base de données Analyze Amazon Aurora My SQL 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 la section Variables d'état du serveur dans la section Ma SQL documentation.

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.