synch/mutex/innodb/fil_system_mutex

El evento synch/mutex/innodb/fil_system_mutex se produce cuando una sesión está a la espera para acceder a la memoria caché de memoria del espacio de tabla.

Versiones del motor admitidas

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

• Aurora MySQL, versiones 2 y 3

Context

InnoDB utiliza espacios de tabla para administrar el área de almacenamiento de las tablas y archivos de registro. La caché de memoria del espacio de tabla es una estructura de memoria global que mantiene información sobre los espacios de tabla. MySQL utiliza las esperas synch/mutex/innodb/fil_system_mutex para controlar el acceso simultáneo a la caché de memoria del espacio de tabla.

El evento synch/mutex/innodb/fil_system_mutex indica que actualmente hay más de una operación que necesita recuperar y manipular información en la caché de memoria del espacio de tabla para el mismo espacio de tabla.

Causas probables del aumento de las esperas

Cuando el evento synch/mutex/innodb/fil_system_mutex aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, esto suele deberse a la presencia de las condiciones siguientes:

• Aumento de las operaciones simultáneas de lenguaje de manipulación de datos (DML) que actualizan o eliminan datos de la misma tabla.

• El espacio de tabla de esta tabla es muy grande y tiene muchas páginas de datos.

• El factor de relleno de estas páginas de datos es bajo.

Acciones

Recomendamos diferentes acciones en función de las causas del evento de espera.

Temas

• Identificar las sesiones y consultas que provocan los eventos
• Reorganizar grandes tablas durante las horas de menor actividad

Identificar las sesiones y consultas que provocan los eventos

Normalmente, las bases de datos con una carga de moderada a significativa tienen eventos de espera. Los eventos de espera pueden ser aceptables si el rendimiento es óptimo. Si el rendimiento no es óptimo, examine dónde pasa más tiempo la base de datos. Preste atención a los eventos de espera que contribuyen a la carga más alta y averigüe si puede optimizar la base de datos y la aplicación para reducirlos.

Para buscar consultas SQL responsables de cargas elevadas

1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

2. En el panel de navegación, seleccione Información sobre rendimiento.

3. Elija una instancia de base de datos. Se muestra el panel Información sobre rendimiento para dicha instancia de base de datos.

4. En el cuadro Database load (Carga de base de datos), elija Slice by wait (Corte por espera).

5. En la parte inferior de la página, elija Top SQL (SQL principal).

   El gráfico enumera las consultas SQL responsables de la carga. Las que están en la parte superior de la lista son las más importantes. Para resolver un cuello de botella, céntrese en estas instrucciones.

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.

Otra forma de averiguar qué consultas están causando un gran número de esperas synch/mutex/innodb/fil_system_mutex consiste en verificar performance_schema, como en el ejemplo siguiente.

mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
            THREAD_ID: 19
             EVENT_ID: 195057
         END_EVENT_ID: 195057
           EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
               SOURCE: fil0fil.cc:6700
          TIMER_START: 1010146190118400
            TIMER_END: 1010146196524000
           TIMER_WAIT: 6405600
                SPINS: NULL
        OBJECT_SCHEMA: NULL
          OBJECT_NAME: NULL
           INDEX_NAME: NULL
          OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
     NESTING_EVENT_ID: NULL
   NESTING_EVENT_TYPE: NULL
            OPERATION: lock
      NUMBER_OF_BYTES: NULL
                FLAGS: NULL
*************************** 2. row ***************************
            THREAD_ID: 23
             EVENT_ID: 5480
         END_EVENT_ID: 5480
           EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
               SOURCE: fil0fil.cc:5906
          TIMER_START: 995269979908800
            TIMER_END: 995269980159200
           TIMER_WAIT: 250400
                SPINS: NULL
        OBJECT_SCHEMA: NULL
          OBJECT_NAME: NULL
           INDEX_NAME: NULL
          OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
     NESTING_EVENT_ID: NULL
   NESTING_EVENT_TYPE: NULL
            OPERATION: lock
      NUMBER_OF_BYTES: NULL
                FLAGS: NULL
*************************** 3. row ***************************
            THREAD_ID: 55
             EVENT_ID: 23233794
         END_EVENT_ID: NULL
           EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
               SOURCE: fil0fil.cc:449
          TIMER_START: 1010492125341600
            TIMER_END: 1010494304900000
           TIMER_WAIT: 2179558400
                SPINS: NULL
        OBJECT_SCHEMA: NULL
          OBJECT_NAME: NULL
           INDEX_NAME: NULL
          OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
     NESTING_EVENT_ID: 23233786
   NESTING_EVENT_TYPE: WAIT
            OPERATION: lock
      NUMBER_OF_BYTES: NULL
                FLAGS: NULL

Reorganizar grandes tablas durante las horas de menor actividad

Reorganice las tablas de gran tamaño que identifique como origen de un gran número de eventos de espera synch/mutex/innodb/fil_system_mutex durante el periodo de mantenimiento fuera del horario de producción. De este modo, se garantiza que la limpieza de la asignación de los espacios de tabla internos no tenga lugar en momentos en los que el acceso rápido a la tabla es crítico. Para obtener información sobre la reorganización de tablas, consulte OPTIMIZE TABLE Statement en MySQL Reference.