synch/mutex/innodb/trx_sys_mutex - Amazon Aurora

synch/mutex/innodb/trx_sys_mutex

O evento synch/mutex/innodb/trx_sys_mutex ocorre quando há alta atividade de banco de dados com muitas transações.

Versões de mecanismos relevantes

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

  • Aurora MySQL versões 2 e 3

Contexto

Internamente, o mecanismo de banco de dados InnoDB utiliza o nível de isolamento de leitura repetível com snapshots para fornecer consistência de leitura. Isso fornece uma visão pontual do banco de dados na ocasião em que o snapshot foi criado.

No InnoDB, todas as alterações são aplicadas ao banco de dados logo que chegam, independentemente de terem sido confirmadas ou não. Essa abordagem significa que, sem o controle de simultaneidade de várias versões (MVCC), todos os usuários conectados ao banco de dados visualizam todas as alterações e as linhas mais recentes. Portanto, o InnoDB requer uma maneira de acompanhar as alterações para saber o que deve ser revertido quando necessário.

Para fazer isso, o InnoDB utiliza um sistema de transações (trx_sys) para acompanhar snapshots. Esse sistema de transações faz o seguinte:

  • Acompanha o ID da transação para cada linha nos logs de operações desfazer.

  • Usa uma estrutura interna do InnoDB denominada ReadView, que ajuda a identificar quais IDs de transação estão visíveis para um snapshot.

Possíveis causas do maior número de esperas

Qualquer operação de banco de dados que exija manuseio consistente e controlado (criação, leitura, atualização e exclusão) de IDs de transações gera uma chamada de trx_sys para o mutex.

Essas chamadas acontecem dentro de três funções:

  • trx_sys_mutex_enter – Cria o mutex.

  • trx_sys_mutex_exit – Libera o mutex.

  • trx_sys_mutex_own – Testa se existe uma propriedade para o mutex.

A instrumentação do Performance Schema do InnoDB rastreia todas as chamadas de mutex trx_sys. O acompanhamento inclui, mas não se limita a, o gerenciamento de trx_sys na inicialização ou encerramento do banco de dados, operações de reversão, limpezas de operações desfazer, acesso de leitura de linha e cargas de grupo de buffer. A alta atividade do banco de dados com um grande número de transações resulta no surgimento de synch/mutex/innodb/trx_sys_mutex entre os principais eventos de espera.

Para saber mais, consulte o tópico sobre como Monitorar esperar de mutex do InnoDB utilizando o Performance Schema, na documentação do MySQL.

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. 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 AWS Management Console
  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.

Examinar outros eventos de espera

Examine os outros eventos de espera associados ao evento de espera synch/mutex/innodb/trx_sys_mutex. Isso pode fornecer mais informações sobre a natureza da workload. Um número elevado de transações pode reduzir a taxa de transferência, mas a workload também pode tornar isso necessário.

Para obter mais informações sobre como otimizar transações, consulte o tópico sobre como Otimizar o gerenciamento de transações do InnoDB, na documentação do MySQL.