# 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.
**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Contexto](#ams-waits.innodb-fil-system-mutex.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.innodb-fil-system-mutex.causes)
+ [Ações](#ams-waits.innodb-fil-system-mutex.actions)
## 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ões 2 e 3
## 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.
**Topics**
+ [Identificar as sessões e as consultas que estão causando os eventos](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [Reorganizar tabelas grandes no horário fora de pico](#ams-waits.innodb-fil-system-mutex.actions.reorganize)
### 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 Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Performance Insights**.
1. Escolha uma instância de banco de dados. O painel do Performance Insights é exibido para essa instância de banco de dados.
1. No gráfico **Database load** (Carga de banco de dados), escolha **Slice by wait** (Segmentar por espera).
1. 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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-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](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html), na *Referência do MySQL*.