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.

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, 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.

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/.

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. 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.

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 obter mais informações, consulte Usar o Amazon Aurora Auto Scaling com réplicas do Aurora.

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, 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.

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.