synch/mutex/innodb/aurora_lock_thread_slot_futex

L'événement synch/mutex/innodb/aurora_lock_thread_slot_futex se produit lorsqu'une session a verrouillé une ligne pour une mise à jour et qu'une autre session tente de mettre à jour cette même ligne. Pour plus d'informations, consultez InnoDB locking dans la Référence MySQL.

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 2

Note

Dans Aurora MySQL versions 3.01.0 et 3.01.1, cet événement d'attente est indiqué comme io/table/sql/handler.

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

Plusieurs instructions en langage de manipulation de données (DML) accèdent simultanément aux mêmes lignes.

Actions

Nous recommandons différentes actions en fonction des autres événement d'attente que vous voyez.

Rechercher et répondre aux instructions SQL responsables de cet événement d'attente

Utilisez Performance Insights pour identifier les instructions SQL responsables de cet événement d'attente. Envisagez les stratégies suivantes :

• Si les verrous de ligne posent un problème persistant, pensez à réécrire l'application de manière à utiliser un verrouillage optimiste.

• Utiliser plusieurs instructions

• Répartissez la charge de travail sur différents objets de base de données. Vous pouvez le faire via le partitionnement.

• Vérifiez la valeur du paramètre innodb_lock_wait_timeout. Il contrôle le délai d'attente des transactions avant de générer une erreur de dépassement.

Pour une vue d'ensemble de la résolution des problème à l'aide de Performance Insights, consultez le billet de blogAnalyze Amazon Aurora MySQL Workloads with Performance Insights.

Rechercher et répondre à la session de blocage

Déterminez si la session de blocage est active ou inactive. Vérifiez également si la session provient d'une application ou d'un utilisateur actif.

Pour identifier la session maintenant le verrou, vous pouvez exécuter SHOW ENGINE INNODB STATUS. L'exemple suivant illustre une sortie.

mysql> SHOW ENGINE INNODB STATUS;

---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0

Vous pouvez également utiliser la requête suivante pour extraire des détails sur les verrous en cours.

mysql> SELECT p1.id waiting_thread,
              p1.user waiting_user,
              p1.host waiting_host,
              it1.trx_query waiting_query,        
              ilw.requesting_trx_id waiting_transaction, 
              ilw.blocking_lock_id blocking_lock, 
              il.lock_mode blocking_mode,
              il.lock_type blocking_type,
              ilw.blocking_trx_id blocking_transaction,
              CASE it.trx_state 
                WHEN 'LOCK WAIT' 
                THEN it.trx_state 
                ELSE p.state 
              END blocker_state, 
              il.lock_table locked_table,        
              it.trx_mysql_thread_id blocker_thread, 
              p.user blocker_user, 
              p.host blocker_host 
       FROM information_schema.innodb_lock_waits ilw 
       JOIN information_schema.innodb_locks il 
         ON ilw.blocking_lock_id = il.lock_id 
        AND ilw.blocking_trx_id = il.lock_trx_id
       JOIN information_schema.innodb_trx it 
         ON ilw.blocking_trx_id = it.trx_id
       JOIN information_schema.processlist p 
         ON it.trx_mysql_thread_id = p.id 
       JOIN information_schema.innodb_trx it1 
         ON ilw.requesting_trx_id = it1.trx_id 
       JOIN information_schema.processlist p1 
         ON it1.trx_mysql_thread_id = p1.id\G

*************************** 1. row ***************************
      waiting_thread: 3561959471
        waiting_user: reinvent
        waiting_host: 123.456.789.012:20485
       waiting_query: select id1 from test.t1 where id1=1 for update
 waiting_transaction: 312337314
       blocking_lock: 312337287:261:3:2
       blocking_mode: X
       blocking_type: RECORD
blocking_transaction: 312337287
       blocker_state: User sleep
        locked_table: `test`.`t1`
      blocker_thread: 3561223876
        blocker_user: reinvent
        blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)

Après avoir identifié la session, vous pouvez procédez comme suit :

• Contactez le propriétaire de l'application ou l'utilisateur.

• Si la session de blocage est inactive, pensez à y mettre fin. Une telle action peut déclencher une longue restauration. Pour savoir comment mettre fin à une session, consultez Mettre fin à une session ou à une requête.

Pour en savoir plus sur l'identification des transactions de blocage, consultez Using InnoDB Transaction and Locking Information dans le Manuel de référence MySQL.