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
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
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.
Tópicos
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
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 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:
-
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. -
Recupere as principais tabelas das visualizações
schema_table_statisticsex$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:
-
O artigo Is Adaptive Hash Index in InnoDB right for my workload?
, no site da Percona -
Adaptive Hash Index
, no Manual de referência do MySQL -
O artigo Contention in MySQL InnoDB: Useful Info From the Semaphores Section
, no site da Percona
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.
