synch/mutex/innodb/aurora_lock_thread_slot_futex - Amazon Aurora
Versiones del motor admitidasCausas probables del aumento de las esperasAcciones

synch/mutex/innodb/aurora_lock_thread_slot_futex

El evento synch/mutex/innodb/aurora_lock_thread_slot_futex se produce cuando una sesión ha bloqueado una fila para una actualización y otra sesión intenta actualizar la misma fila. Para obtener información, consulte InnoDB Locking en MySQL Reference.

Versiones del motor admitidas

Esta información de evento de espera es compatible con las siguientes versiones del motor:

  • Aurora MySQL versión 2

nota

En las versiones 3.01.0 y 3.01.1 de Aurora MySQL, este evento de espera se indica como io/table/sql/handler.

Causas probables del aumento de las esperas

Las múltiples instrucciones de lenguaje de manipulación de datos (DML) tienen acceso a la misma fila o filas simultáneamente.

Acciones

Recomendamos diferentes acciones en función de los demás eventos de espera que vea.

Buscar y responder a las instrucciones SQL responsables de este evento de espera

Utilice Información sobre rendimiento para identificar las instrucciones SQL responsables de este evento de espera. Consideremos la posibilidad de aplicar las estrategias siguientes:

  • Si los bloqueos de fila son un problema persistente, considere la posibilidad de reescribir la aplicación para utilizar un bloqueo optimista.

  • Utilice instrucciones de varias filas.

  • Distribuya la carga de trabajo en distintos objetos de base de datos. Puede hacerlo mediante una partición.

  • Verifique el valor del parámetro innodb_lock_wait_timeout. Controla cuánto tiempo esperan las transacciones antes de generar un error de tiempo de espera.

Para obtener información general útil sobre la solución de problemas mediante Información sobre rendimiento, consulte la entrada de blog Analyze Amazon Aurora MySQL Workloads with Performance Insights.

Buscar y responder a la sesión de bloqueo

Determine si la sesión de bloqueo está inactiva o activa. Además, averigüe si la sesión procede de una aplicación o de un usuario activo.

Para identificar la sesión que mantiene el candado, puede ejecutar SHOW ENGINE INNODB STATUS. A continuación se muestra un resultado de ejemplo.

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

O bien, puede utilizar la siguiente consulta para extraer detalles sobre los bloqueos actuales.

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)

Cuando identifique la sesión, puede seguir una de las opciones siguientes:

  • Ponerse en contacto con el propietario o el usuario de la aplicación.

  • Si la sesión de bloqueo está inactiva, considere la posibilidad de finalizar la sesión de bloqueo. Esta acción podría desencadenar una larga restauración. Para aprender a finalizar una sesión, consulte Finalización de una sesión o una consulta.

Para obtener más información acerca de cómo identificar las transacciones de bloqueo, consulte Using InnoDB Transaction and Locking Information en MySQL Reference Manual.