O I/O elevado em uma instância do ApsaraDB RDS for MySQL geralmente decorre de cinco causas principais: throughput alto, tabelas temporárias, leitura de dados frios, instruções DDL e gravações de binary log por transações grandes. Use este guia para identificar a causa e adotar medidas específicas.
Visão geral das causas comuns
|
Causa |
Onde verificar no console |
Indicador principal |
|
Throughput alto |
Autonomy Service > Dashboard > Performance Trends |
Carga de leitura/gravação |
|
Tabelas temporárias |
Autonomy Service > Dashboard > Performance Trends |
Tamanho do diretório |
|
Leitura de dados frios |
Autonomy Service > Dashboard > Performance Trends |
Taxa de acerto do buffer pool |
|
Instruções DDL |
Monitoring and Alerts > Standard Monitoring > Standard View |
Uso de disco e IOPS |
|
Gravações de binary log por transações grandes |
— |
Aumento repentino e significativo no volume de binary log |
Como o InnoDB gerencia o I/O
O InnoDB usa um sistema de I/O independente para ler e gravar páginas de dados. Quando uma instrução SQL solicita uma página de dados ausente no buffer pool, o InnoDB a lê do disco com I/O síncrono. Threads em segundo plano usam I/O assíncrono para liberar páginas sujas (dirty pages) no disco.
Além do I/O de arquivos de dados, outras operações podem aumentar significativamente o I/O: gravações de redo log, undo log e binary log, ordenação de tabelas temporárias e reconstruções de tablespace por DDL. Cada uma das cinco causas abaixo corresponde a um ou mais desses mecanismos.
Solucionar I/O elevado causado por throughput alto
Sintoma
Operações frequentes de UPDATE, DELETE e INSERT em tabelas com muitos índices ou campos grandes geram I/O de duas formas. Primeiro, o RDS lê páginas de dados para o buffer pool. Em seguida, threads em segundo plano liberam as páginas sujas resultantes no disco. A pressão combinada de leitura e gravação eleva o I/O.
Para confirmar, acesse Autonomy Service > Dashboard no painel de navegação à esquerda do console do ApsaraDB RDS, abra a aba Performance Trends e verifique as métricas de carga de leitura e gravação.
Solução
Reduza a frequência de leitura e gravação, faça upgrade do tipo da instância ou ajuste os parâmetros que controlam a liberação de páginas sujas.
|
Parâmetro |
Padrão |
Descrição |
|
|
75 |
Percentual máximo de páginas sujas permitido no buffer pool |
|
|
0 (desativado) |
Limiar inferior para páginas sujas; quando excedido, o RDS libera proativamente páginas sujas para manter espaço livre no buffer pool |
|
|
20000 |
Máximo de operações de I/O por segundo disponível para tarefas em segundo plano do InnoDB; controla a velocidade de liberação de páginas sujas e gravações no buffer pool |
|
|
40000 |
Limite superior de operações de I/O por segundo; entra em vigor apenas quando a liberação de páginas sujas fica atrasada; deve ser maior que |
O valor de innodb_max_dirty_pages_pct_lwm deve ser menor ou igual a innodb_max_dirty_pages_pct. Se você definir um valor maior, o RDS o redefinirá automaticamente para o valor de innodb_max_dirty_pages_pct.
Solucionar I/O elevado causado por tabelas temporárias
Sintoma
Instruções SQL lentas que envolvem ordenação ou deduplicação fazem o InnoDB criar grandes tabelas temporárias no disco. Tanto a criação quanto a gravação nessas tabelas temporárias aumentam o I/O. Um diretório tmp grande é um indicador confiável.
Para confirmar, acesse Autonomy Service > Dashboard no painel de navegação à esquerda do console do ApsaraDB RDS, abra a aba Performance Trends e verifique o tamanho do diretório tmp.
Solução
Otimize as instruções SQL que geram tabelas temporárias. O Database Autonomy Service (DAS) oferece otimização de SQL integrada para ajudar a identificar e corrigir consultas lentas. Para mais detalhes, consulte Otimização de SQL.
Solucionar I/O elevado causado por leitura de dados frios
Sintoma
Quando as páginas de dados necessárias para uma consulta ou instrução DML não estão no buffer pool, o InnoDB as lê do disco. Uma taxa de acerto baixa no buffer pool significa que a maioria das solicitações vai para o disco, aumentando significativamente o I/O.
Para confirmar, acesse Autonomy Service > Dashboard no painel de navegação à esquerda do console do ApsaraDB RDS, abra a aba Performance Trends e verifique a taxa de acerto do buffer pool.
Solução
Redesenhe sua estratégia de cache com base nos padrões de acesso da sua carga de trabalho. Como alternativa, faça upgrade da sua instância RDS.
Solucionar I/O elevado causado por instruções DDL
Sintoma
Instruções DDL acionam uma reconstrução completa do tablespace. O InnoDB verifica cada linha, cria índices de ordenação e libera páginas sujas para a nova estrutura da tabela. A exclusão de tabelas grandes também gera I/O significativo. Essas operações podem causar picos abruptos tanto no uso de disco quanto no IOPS.
Para confirmar, acesse Monitoring and Alerts no painel de navegação à esquerda do console do ApsaraDB RDS, clique em Standard View na aba Standard Monitoring e verifique o uso de disco e o IOPS.
Solução
Use o recurso Purge Large File Asynchronously para excluir arquivos grandes sem bloquear o I/O. Esse recurso faz parte do AliSQL, a ramificação do MySQL da Alibaba Cloud. Para mais detalhes, consulte Purge Large File Asynchronously.
Solucionar I/O elevado causado por gravações de binary log de transações grandes
Sintoma
O InnoDB grava em arquivos de binary log apenas no commit da transação. Uma única transação grande — por exemplo, um DELETE que remove um grande número de linhas — pode gerar dezenas de GB de dados de binary log. Liberar esse volume no disco de uma só vez causa um pico abrupto de I/O.
Solução
Divida transações grandes em lotes menores. Commits menores distribuem as liberações de binary log ao longo do tempo, reduzem as liberações de páginas sujas no disco e evitam o I/O em rajada que um único commit grande produz.