synch/mutex/innodb/fil_system_mutex - Amazon Aurora
Versões compatíveis do mecanismoContextoPossíveis causas do maior número de esperasAções

synch/mutex/innodb/fil_system_mutex

O evento synch/mutex/innodb/fil_system_mutex ocorre quando uma sessão está aguardando para acessar o cache de memória do espaço de tabelas.

Versões compatíveis do mecanismo

Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:

  • Aurora MySQL versão 2, até 2.09.2

  • Aurora MySQL versão 1, até 1.23.1

Contexto

O InnoDB utiliza espaços de tabela para gerenciar a área de armazenamento de tabelas e arquivos de log. O cache de memória de espaços de tabela é uma estrutura de memória global que mantém informações sobre espaços de tabela. O MySQL usa esperas synch/mutex/innodb/fil_system_mutex para controlar o acesso simultâneo ao cache de memória de espaços de tabela.

O evento synch/mutex/innodb/fil_system_mutex indica que atualmente há mais de uma operação que precisa recuperar e manipular informações no cache de memória de espaços de tabela para o mesmo espaço de tabela.

Possíveis causas do maior número de esperas

Quando o evento synch/mutex/innodb/fil_system_mutex aparece mais que o normal, possivelmente indicando um problema de performance, isso geralmente ocorre quando todas as seguintes condições estão presentes:

  • Aumento nas operações simultâneas da linguagem de manipulação de dados (DML) que atualizam ou excluem dados na mesma tabela.

  • O espaço de tabela desta tabela é muito grande e tem muitas páginas de dados.

  • O fator para preenchimento dessas páginas de dados é baixo.

Ações

Recomenda-se ações distintas, dependendo dos motivos do evento de espera.

Identificar as sessões e as consultas que estão causando os eventos

Em geral, bancos de dados com carga de moderada a significativa apresentam eventos de espera. Os eventos de espera podem ser aceitáveis quando a performance é ideal. Se a performance não for ideal, examine onde o banco de dados está passando a maior parte do tempo. Observe os eventos de espera que contribuem para a carga mais alta e descubra se é possível otimizar o banco de dados e a aplicação para reduzir esses eventos.

Para localizar consultas SQL que são responsáveis pela carga alta

  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, escolha Performance Insights.

  3. Escolha uma instância de banco de dados. O painel do Performance Insights é exibido para essa instância de banco de dados.

  4. No gráfico Database load (Carga de banco de dados), escolha Slice by wait (Segmentar por espera).

  5. Na parte inferior da página, escolha Top SQL (SQL principal).

    O gráfico mostra as consultas SQL que são responsáveis pela carga. Os que estão no topo da lista são os mais responsáveis. Para solucionar um gargalo, concentre-se nessas instruções.

Para obter uma visão geral útil da solução de problemas de uso do Performance Insights, consulte a Publicação no blog sobre como Analisar workloads do Amazon Aurora MySQL com o Performance Insights.

Outra maneira de descobrir quais consultas estão causando muitas esperas synch/mutex/innodb/fil_system_mutex é verificar performance_schema, como no exemplo a seguir.

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 tabelas grandes no horário fora de pico

Reorganize tabelas grandes que você identifica como a fonte de números elevados de eventos de espera synch/mutex/innodb/fil_system_mutex durante uma janela de manutenção fora do horário de produção. Isso garante que a limpeza do mapa de espaços de tabela internos não ocorra quando o acesso rápido à tabela for essencial. Para obter informações sobre como reorganizar tabelas, consulte a Instrução OPTIMIZE TABLE, na Referência do MySQL.