View a markdown version of this page

io/table/sql/handler - Amazon Aurora
Versões compatíveis do mecanismoContextoPossíveis causas do maior número de esperasAções

io/table/sql/handler

O evento io/table/sql/handler ocorre quando o trabalho foi delegado a um mecanismo de armazenamento.

Versões compatíveis do mecanismo

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

  • Aurora MySQL versões 2 e 3

Contexto

O evento io/table indica uma espera pelo acesso a uma tabela. Esse evento ocorre não importa se os dados estão armazenados em cache no grupo de buffer ou acessados no disco. O evento io/table/sql/handler indica um aumento na atividade da workload.

Um manipulador é uma rotina especializada em um determinado tipo de dados ou focada em certas tarefas especiais. Por exemplo, um manipulador de eventos recebe e digere eventos e sinais provenientes do sistema operacional ou de uma interface de usuário. Um manipulador de memória realiza tarefas relacionadas a memória. Um manipulador de entrada de arquivo é uma função que recebe a entrada de arquivos e realiza tarefas especiais nos dados de acordo com o contexto.

Visualizações como performance_schema.events_waits_current muitas vezes indicam io/table/sql/handler quando a espera real é um evento de espera aninhado, como um bloqueio. Quando a espera real não é io/table/sql/handler, o Performance Insights relata o evento de espera aninhado. Quando o Performance Insights relata io/table/sql/handler, isso representa o processamento de InnoDB da solicitação de E/S e não um evento de espera aninhado oculto. Para saber mais, consulte o tópico sobre Eventos "átomo" e "molécula" no Performance Schema, no Manual de referência do MySQL.

O evento io/table/sql/handler costuma aparecer nos principais eventos de espera com esperas de E/S, como io/aurora_redo_log_flush.

Possíveis causas do maior número de esperas

No Performance Insights, picos repentinos no evento io/table/sql/handler indicam aumento na atividade da workload. O aumento da atividade significa E/S elevada.

O Performance Insights filtra os IDs de eventos de aninhamento e não informa uma espera io/table/sql/handler quando o evento aninhado subjacente é uma espera de bloqueio. Por exemplo, se o evento da causa raiz for synch/mutex/innodb/aurora_lock_thread_slot_futex, o Performance Insights exibirá essa espera nos principais eventos de espera, e não em io/table/sql/handler.

Em visualizações como performance_schema.events_waits_current, esperas por io/table/sql/handler geralmente aparecem quando a espera real é um evento de espera aninhado, como um bloqueio. Quando a espera real é diferente de io/table/sql/handler, o Performance Insights procura a espera aninhada e relata a espera real em vez de io/table/sql/handler. Quando o Performance Insights relata io/table/sql/handler, a espera real é io/table/sql/handler, e não um evento de espera aninhado oculto. Para saber mais, consulte o tópico sobre Eventos "átomo" e "molécula" no Performance Schema, no Manual de referência do MySQL 5.7.

Ações

Se esse evento de espera domina a atividade do banco de dados, isso não indica necessariamente um problema de performance. Um evento de espera está sempre na parte superior quando o banco de dados está ativo. Você precisará reagir somente quando a performance piorar.

Recomendamos diferentes ações dependendo dos outros eventos de espera exibidos.

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 localizar consultas SQL que são responsáveis pela carga alta

  1. Faça login no Console de gerenciamento da AWS 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. Escolha a guia Top SQL (SQL principal).

    O gráfico mostra as consultas SQL que são responsáveis pela carga. Os itens listados primeiro são os que mais contribuem. 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.

Verifique se existe uma correlação com as métricas de contadores do Performance Insights

Verifique as métricas do contador do Performance Insights, como Innodb_rows_changed. Se as métricas de contadores estiverem correlacionadas com io/table/sql/handler, siga estas etapas:

  1. No Performance Insights, procure as instruções SQL que representam o evento de espera principal io/table/sql/handler. Se possível, otimize essa instrução de forma que ela retorne menos linhas.

  2. Recupere as principais tabelas das visualizações schema_table_statistics e x$schema_table_statistics. Essas visualizações mostram o tempo gasto por tabela. Para ter mais informações, consulte As visualizações schema_table_statistics e x$schema_table_statistics, no Manual de referência do MySQL.

    Por padrão, as linhas são classificadas por tempo de espera total em ordem decrescente. Tabelas com mais disputa aparecem primeiro. A saída indica se o tempo é gasto em buscas, inserções, leituras, gravações, atualizações ou exclusões.

    mysql> select * from sys.schema_table_statistics limit 1\G

*************************** 1. row ***************************
     table_schema: read_only_db
       table_name: sbtest41
    total_latency: 54.11 m
     rows_fetched: 6001557
    fetch_latency: 39.14 m
    rows_inserted: 14833
   insert_latency: 5.78 m
     rows_updated: 30470
   update_latency: 5.39 m
     rows_deleted: 14833
   delete_latency: 3.81 m
 io_read_requests: NULL
          io_read: NULL
  io_read_latency: NULL
io_write_requests: NULL
         io_write: NULL
 io_write_latency: NULL
 io_misc_requests: NULL
  io_misc_latency: NULL
1 row in set (0.11 sec)

Verificar se existem outros eventos de espera correlacionados

Se synch/sxlock/innodb/btr_search_latch e io/table/sql/handler forem juntos os principais colaboradores para a anomalia de carga de banco de dados, verifique se a variável innodb_adaptive_hash_index está habilitada. Se estiver, considere aumentar o valor do parâmetro innodb_adaptive_hash_index_parts.

Se o Adaptive Hash Index estiver desabilitado, considere habilitá-lo. Para saber mais sobre o Adaptive Hash Index do MySQL, consulte os seguintes recursos:

nota

O Adaptive Hash Index não é compatível com instâncias de banco de dados de leitor do Aurora.

Em alguns casos, a performance pode ser ruim em uma instância de leitor quando synch/sxlock/innodb/btr_search_latch e io/table/sql/handler são dominantes. Em caso afirmativo, considere redirecionar a workload temporariamente à instância de banco de dados de gravador e habilitar o Adaptive Hash Index.