synch/rwlock/innodb/hash_table_locks - Amazon Aurora

synch/rwlock/innodb/hash_table_locks

O evento synch/rwlock/innodb/hash_table_locks ocorre quando há disputa na modificação da tabela de hash que faz o mapeamento do cache de buffer.

Versões compatíveis do mecanismo

Essas informações de evento de espera têm suporte no Aurora MySQL versão 1 até 1.23.1.

Contexto

O evento synch/rwlock/innodb/hash_table_locks indica que há disputa na modificação da tabela de hash que faz o mapeamento do cache de buffer. Uma tabela de hash é uma tabela na memória projetada para melhorar a performance do acesso ao grupo de buffer. Esse evento de espera é invocado quando a tabela de hash precisa ser modificada.

Para obter mais informações, consulte o tópico sobre o Grupo de buffer, na documentação do MySQL.

Possíveis causas do maior número de esperas

Quando o evento synch/rwlock/innodb/hash_table_locks aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:

Um grupo de buffers subdimensionado

O tamanho do grupo de buffer é muito pequeno para manter na memória todas as páginas frequentemente acessadas.

Workload pesada

A workload está causando despejos frequentes e recarregamentos de páginas de dados no cache de buffer.

Ações

Recomenda-se ações distintas, dependendo dos motivos do evento de espera.

Aumentar o tamanho do grupo de buffer

Certifique-se de que o grupo de buffer esteja apropriadamente escalado para a workload. Para isso, é possível verificar a taxa de acertos do cache do grupo de buffer. Em geral, se o valor cair abaixo de 95%, considere aumentar o tamanho do grupo de buffer. Um grupo de buffer maior pode manter por mais tempo na memória as páginas acessadas com frequência.

Para aumentar o tamanho do grupo de buffer, modifique o valor do parâmetro innodb_buffer_pool_size. O valor padrão desse parâmetro baseia-se no tamanho da classe da instância de banco de dados. Para obter mais informações, consulte a publicação no Blog de banco de dados da AWS sobre Práticas recomendadas de configuração de parâmetros para o Amazon RDS for MySQL, parte 1: Parâmetros relacionados a performance.

Melhorar padrões de acesso a dados

Confira as consultas afetadas por essa espera e seus planos de execução. Considere melhorar padrões de acesso a dados. Por exemplo, se você estiver utilizando mysqli_result::fetch_array, poderá tentar aumentar o tamanho da busca das matrizes.

É possível utilizar o Performance Insights para mostrar consultas e sessões que possam estar causando o evento de espera synch/rwlock/innodb/hash_table_locks.

Localizar consultas SQL responsáveis pela alta carga

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 AWS Management Console e 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. 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 AWSPublicação no blog de banco de dados sobre como Analisar workloads do Amazon Aurora MySQL com o Performance Insights.

Reduzir ou evitar varreduras de tabelas inteiras

Monitore sua workload para ver se ela está executando varreduras de tabelas inteiras e, se estiver, reduza ou evite essas varreduras. Por exemplo, é possível monitorar variáveis de status como Handler_read_rnd_next. Para obter mais informações, consulte o tópico sobre Variáveis de status do servidor, na documentação do MySQL.