synch/sxlock/innodb/hash_table_locks
O evento synch/sxlock/innodb/hash_table_locks ocorre quando as páginas não encontradas no grupo de buffer devem ser lidas do armazenamento.
Versões compatíveis do mecanismo
Essas informações de eventos de espera têm suporte nas seguintes versões:
-
Aurora MySQL versões 2 e 3
Contexto
O evento synch/sxlock/innodb/hash_table_locks indica que uma workload está acessando com frequência dados que não estão armazenados no grupo de buffer. Esse evento de espera está associado a novas adições de página e remoções de dados antigos do grupo de buffer. Os dados armazenados no grupo de buffer antigos e os dados novos devem ser armazenados em cache, para que as páginas antigas sejam despejadas de forma a permitir o armazenamento em cache das novas páginas. O MySQL aplica um algoritmo menos utilizado recentemente (LRU) para expulsar páginas do grupo de buffers. A workload está tentando acessar dados que não foram carregados no grupo de buffer ou dados que foram despejados do grupo de buffer.
Esse evento de espera ocorre quando a workload deve acessar os dados em arquivos no disco ou quando os blocos são liberados ou adicionados à lista de LRUs do grupo de buffer. Essas operações esperam até obter um bloqueio excluído compartilhado (SX-lock). Esse SX-lock é utilizado para a sincronização na tabela de hash, uma tabela na memória projetada para melhorar a performance do acesso ao grupo de buffer.
Para obter mais informações, consulte o tópico sobre o Grupo de buffer
Possíveis causas do maior número de esperas
Quando o evento de espera synch/sxlock/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.
- Erros de leitura das páginas
-
Ocorrem erros ao ler páginas no grupo de buffer, o que pode indicar corrupção dos dados.
Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
Tópicos
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 Práticas recomendadas para a configuração do banco de dados do Amazon Aurora MySQL
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
É possível utilizar o Performance Insights para mostrar consultas e sessões que possam estar causando o evento de espera synch/sxlock/innodb/hash_table_locks.
Para localizar consultas SQL que são responsáveis pela carga alta
Faça login no AWS Management Console e 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).
-
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
Verificar se há páginas corrompidas nos logs de erros
É possível consultar mysql-error.log em busca de mensagens relacionadas a corrupções que foram detectadas perto do momento do problema. As mensagens com as quais é possível trabalhar para solucionar o problema estão no log de erros. Talvez seja necessário recriar objetos que foram sinalizados como corrompidos.
