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
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
Abra o console do Amazon RDS em https://console.aws.amazon.com/rds/
. -
No painel de navegação, escolha Performance Insights.
-
Escolha uma instância de banco de dados. O painel do Performance Insights é exibido para essa instância de banco de dados.
-
No gráfico Database load (Carga de banco de dados), escolha Slice by wait (Segmentar por espera).
-
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