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ão 3: 3.01.0 e 3.01.1

  • Aurora MySQL versão 2

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.

nota

No entanto, nas versões 3.01.0 e 3.01.1 do Aurora MySQL, synch/mutex/innodb/aurora_lock_thread_slot_futex é relatado como io/table/sql/handler.

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

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.

nota

No entanto, nas versões 3.01.0 e 3.01.1 do Aurora MySQL, synch/mutex/innodb/aurora_lock_thread_slot_futex é relatado como io/table/sql/handler.

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 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 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. O exemplo a seguir foi executado em uma instância do Aurora MySQL 2.09.1.

    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.