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ção 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 elevam o 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 aumenta 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 leituras e gravações, 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 com 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 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 identificar e corrigir consultas lentas. Para mais detalhes, consulte SQL optimization.
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 indica que a maioria das solicitações vai para o disco, o que aumenta 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 carga de trabalho. Como alternativa, faça upgrade da 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 nos 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.