io/file/innodb/innodb_data_file

O evento io/file/innodb/innodb_data_file ocorre quando há threads aguardando operações de E/S do 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 1, até 1.23.1

Contexto

O Grupo de buffer do InnoDB é a área de memória compartilhada na qual o Aurora MySQL armazena dados de tabela e índice em cache. As consultas podem acessar dados utilizados com frequência diretamente da memória sem fazer a leitura do disco. O evento io/file/innodb/innodb_data_file indica que o processamento da consulta requer uma operação de E/S de armazenamento porque os dados não estão disponíveis no grupo de buffer.

Em geral, o RDS gera esse evento ao executar operações de E/S, como leituras, gravações ou liberações. O RDS também gera esse evento ao executar instruções de linguagem de definição de dados (DDL). Isso acontece porque essas instruções envolvem operações de criar, excluir, abrir, fechar ou renomear arquivos de dados do InnoDB.

Possíveis causas do maior número de esperas

Quando esse evento aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:

• Um pico na workload de uma aplicação com alto consumo de E/S pode aumentar a ocorrência desse evento de espera, pois mais consultas precisam ler do armazenamento.

  Um aumento significativo no número de páginas que estão sendo varridas faz com que as páginas menos recém-utilizadas (LRU) sejam despejadas do grupo de buffer a uma taxa mais rápida. Planos de consulta ineficientes podem contribuir para esse problema. Planos de consulta podem ser ineficientes devido a estados desatualizados, índices ausentes ou consultas ineficientemente gravadas.

• A capacidade de armazenamento é suficiente, mas a taxa de transferência da rede excede a largura de banda máxima da classe de instância, causando o controle de utilização de E/S. Para obter informações sobre a capacidade de taxa de transferência da rede de diferentes classes de instância, consulte Especificações de hardware para classes de instância de banco de dados para o Aurora.

• Operações envolvendo instruções DDL ou transações que leem, inserem ou modificam um grande número de linhas. Por exemplo, inserções em massa ou instruções de atualização ou exclusão podem especificar diversos valores na cláusula WHERE.

• Consultas SELECT que varrem muitas linhas. Por exemplo, consultas que usam cláusulas BETWEEN ou IN podem especificar intervalos amplos de dados.

• Uma baixa taxa de acertos do grupo de buffer porque este é muito pequeno. Quanto menor o grupo de buffer, maior a frequência de liberação de páginas LRU. Isso aumenta a probabilidade de que os dados solicitados sejam lidos a partir do disco.

Ações

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

Tópicos

• Identificar e otimizar consultas com problemas
• Aumentar a escala da sua instância na vertical
• Tornar sua varredura de buffer resistente

Identificar e otimizar consultas com problemas

Encontre o resumo da consulta responsável por essa espera no Performance Insights. Verifique o plano de execução da instrução da consulta para ver se ela pode ser otimizada para ler menos páginas no grupo de buffer do InnoDB. Isso diminui o número de páginas menos recém-utilizadas que são despejadas do grupo de buffer. Isso aumenta a eficiência do acerto de cache do grupo de buffer, diminuindo assim a carga no subsistema de E/S.

Para verificar o plano de execução de instruções de uma consulta, execute a instrução EXPLAIN. Esse comando mostra as etapas individuais envolvidas na execução da consulta. Para obter mais informações, consulte o tópico sobre como Otimizar operações de bloqueio, na documentação do MySQL.

Aumentar a escala da sua instância na vertical

Se os seus eventos de espera io/file/innodb/innodb_data_file são causados pela capacidade insuficiente da rede ou do grupo de buffer, considere aumentar a escala vertical da sua instância do RDS para um tipo de classe de instância superior.

• Taxa de transferência da rede: verifique se há um aumento no valor das métricas do Amazon CloudWatch network receive throughput e network transmit throughput. Se sua instância tiver atingido o limite de largura de banda da rede da classe de instância, considere aumentar a escala vertical da sua instância do RDS para um tipo de classe de instância superior. Para mais informações, consulte Especificações de hardware para classes de instância de banco de dados para o Aurora.

• Tamanho do grupo de buffer: verifique se há uma baixa taxa de acertos no grupo de buffer. Para monitorar esse valor no Performance Insights, verifique a métrica db.Cache.innoDB_buffer_pool_hit_rate.avg. Para adicionar essa métrica, escolha Manage metrics (Gerenciar métricas) e escolha innoDB_buffer_pool_hit_rate sob Cache na guia Database metrics (Métricas do banco de dados).

  Se a taxa de acertos for baixa, considere aumentar a escala vertical da sua instância do RDS para um tipo de classe de instância superior.

  nota

  O parâmetro da instância de banco de dados que controla o tamanho do grupo de buffer é innodb_buffer_pool_size. É possível modificar esse valor de parâmetro, mas é preferível aumentar a escala da sua classe de instância na vertical, pois o valor padrão é otimizado para cada classe de instância.

Tornar sua varredura de buffer resistente

Se você tiver uma combinação de consultas de geração de relatórios e processamento de transações online (OLTP), considere tornar a varredura do grupo de buffer resistente. Para fazer isso, ajuste os parâmetros innodb_old_blocks_pct e innodb_old_blocks_time. Os efeitos desses parâmetros podem variar dependendo do hardware, dos dados e do tipo de workload da sua classe de instância. É altamente recomendável gerar um benchmark do seu sistema antes de definir esses parâmetros no seu ambiente de produção. Para obter mais informações, consulte o tópico sobre como Tornar a varredura do buffer resistente, na documentação do MySQL.