# synch/mutex/innodb/buf\_pool\_mutex
O evento `synch/mutex/innodb/buf_pool_mutex` ocorre quando um thread adquire um bloqueio no grupo de buffers do InnoDB para acessar uma página na memória.
**Topics**
+ [Versões de mecanismos relevantes](#ams-waits.bufpoolmutex.context.supported)
+ [Contexto](#ams-waits.bufpoolmutex.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.bufpoolmutex.causes)
+ [Ações](#ams-waits.bufpoolmutex.actions)
## Versões de mecanismos relevantes
Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:
+ Aurora MySQL versão 2
## Contexto
O mutex `buf_pool` é um único mutex que protege as estruturas de dados de controle do grupo de buffer.
Para saber mais, consulte o tópico sobre como [Monitorar esperar de mutex do InnoDB utilizando o Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html), na documentação do MySQL.
## Possíveis causas do maior número de esperas
Este é um evento de espera específico para workload. Causas comuns do surgimento de `synch/mutex/innodb/buf_pool_mutex` entre os principais eventos de espera incluem:
+ O tamanho do grupo de buffer não é suficientemente grande para manter o conjunto de dados de trabalho.
+ A workload é mais específica para determinadas páginas de uma certa tabela no banco de dados, resultando na disputa no grupo de buffer.
## 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.bufpoolmutex.actions.identify)
+ [Utilizar o Performance Insights](#ams-waits.bufpoolmutex.actions.action1)
+ [Criar réplicas do Aurora](#ams-waits.bufpoolmutex.actions.action2)
+ [Examinar o tamanho do grupo de buffer](#ams-waits.bufpoolmutex.actions.action3)
+ [Monitorar o histórico do status global](#ams-waits.bufpoolmutex.actions.action4)
### 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 visualizar o gráfico Top SQL (SQL principal) no Console de Gerenciamento da AWS**
1. 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. Abaixo do gráfico **Database load** (Carga de banco de dados), 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/).
### Utilizar o Performance Insights
Esse evento está relacionado à workload. Você pode utilizar o Performance Insights para fazer o seguinte:
+ Identificar quando eventos de espera são iniciados e se há alguma alteração na workload nesse tempo a partir dos logs da aplicação ou origens relacionadas.
+ Identificar as instruções SQL responsáveis por esse evento de espera. Examinar o plano de execução das consultas para garantir que elas sejam otimizadas e estejam utilizando índices apropriados.
Se as principais consultas responsáveis pelo evento de espera estiverem relacionadas ao mesmo objeto ou tabela de banco de dados, considere particionar esse objeto ou tabela.
### Criar réplicas do Aurora
É possível criar réplicas do Aurora para fornecer tráfego somente leitura. Também é possível pode utilizar o Aurora Auto Scaling para lidar com surtos no tráfego de leitura. Certifique-se de executar tarefas agendadas somente leitura e backups lógicos nas réplicas do Aurora.
Para ter mais informações, consulte [Amazon Aurora Auto Scaling com réplicas do Aurora](Aurora.Integrating.AutoScaling.md).
### Examinar o tamanho do grupo de buffer
Verifique se o tamanho do grupo de buffer é suficiente para a workload, observando a métrica `innodb_buffer_pool_wait_free`. Se o valor dessa métrica for alto e estiver aumentando continuamente, isso indica que o tamanho do grupo de buffer não é suficiente para lidar com a workload. Se `innodb_buffer_pool_size` tiver sido definido corretamente, o valor de `innodb_buffer_pool_wait_free` deverá ser pequeno. Para obter mais informações, consulte [Innodb\_buffer\_pool\_wait\_free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Innodb_buffer_pool_wait_free), na documentação do MySQL.
Aumente o tamanho do grupo de buffer se a instância de banco de dados tiver memória suficiente para buffers de sessão e tarefas do sistema operacional. Se não tiver, altere a instância de banco de dados para uma classe de instância de banco de dados maior a fim de obter memória adicional que possa ser alocada ao grupo de buffer.
**nota**
O Aurora MySQL ajusta automaticamente o valor de `innodb_buffer_pool_instances` com base no valor de `innodb_buffer_pool_size` configurado.
### Monitorar o histórico do status global
Monitorando as taxas de alteração das variáveis de status, é possível detectar problemas de bloqueio ou memória na sua instância de banco de dados. Habilite o histórico de status global (GoSH) se ele ainda não estiver habilitado. Para obter mais informações sobre o GoSH, consulte o tópico sobre como [Gerenciar o histórico de status global](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
Você também pode criar métricas personalizadas do Amazon CloudWatch para monitorar variáveis de status. Para obter mais informações, consulte o tópico sobre como [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html).