ApsaraDB RDS:View RDS for MySQL metrics

Visualizar eventos de desempenho

A área de estatísticas de eventos mostra a contagem de eventos por tipo dentro do intervalo de tempo selecionado. Clique em View Details para abrir a página View Performance Events, onde é possível ver atividades anômalas e eventos de otimização — agendados, em andamento ou concluídos.

Visualizar métricas de desempenho

Na Classic View padrão:

• Clique em More Metrics para selecionar métricas adicionais e visualizar suas tendências de desempenho.

• Clique em após o nome de uma métrica para ver quais submétricas ela contém.

• Clique em Details em qualquer gráfico de tendência para ampliar e ajustar o intervalo de tempo.

• Clique em Add Trend Comparison para comparar a mesma métrica em diferentes períodos.

Analisar eventos nos gráficos de métricas

Na Classic View, selecione um nível de evento para sobrepor os eventos correspondentes nos gráficos de tendência de MySQL CPU/Memory Utilization e Session Connections. Clique em qualquer marcador de evento para visualizar o resultado do diagnóstico.

Executar diagnóstico em um intervalo de tempo

Em qualquer gráfico de tendência de métrica, arraste para selecionar um intervalo de tempo e clique em Diagnose para obter uma análise detalhada da causa raiz desse período.

Usar visualizações de diagnóstico

Clique em qualquer uma das cinco visualizações de diagnóstico para investigar um tipo específico de problema:

• Memory OOM Diagnosis

• Read-only Instance Delay Diagnosis

• Full Disk Space Diagnosis

• CPU Jitter Diagnosis

• Large Transaction Recognition Diagnosis

Para interpretação de métricas e próximos passos de cada visualização, consulte Diagnostic views.

Diagnóstico de OOM de memória

A visualização Memory OOM Diagnosis ajuda a analisar problemas de falta de memória (OOM). Principais métricas e o que elas indicam:

Memory Usage — interprete a tendência em relação ao uso do InnoDB Buffer Pool:

Resident Memory mostra a quantidade de memória física em uso. Open files, Temp File Size, Temp Disk Tables e Sort Rows são indicadores comuns de pressão de memória.

Como eventos de OOM frequentemente encerram os processos que causaram o pico, identificar a instrução SQL exata posteriormente é difícil. Para se preparar:

• Verifique os logs da aplicação quando ocorrerem picos de memória para rastrear a causa.

• Atualize as especificações de memória e ative o SQL Explorer and Audit para que, quando ocorrer um pico, seja possível verificar os tempos de execução das consultas e identificar a causa.

Diagnóstico de atraso em instância somente leitura

A visualização Read-only Instance Delay Diagnosis ajuda a diagnosticar atrasos de replicação em instâncias somente leitura. Principais métricas:

• Active Session: Indica bloqueio por metadata lock. Consultas que varrem grandes volumes de dados impedem que instruções DDL adquiram metadata locks, fazendo com que o DDL bloqueie outras sessões e as conexões se acumulem.

• DML Rows Processed, Pages Requested, DML/DDL Operations, Temp Disk Space Used: Métricas comuns de carga de trabalho da aplicação.

• Replication Delay: O principal indicador de latência.

Diagnóstico de espaço em disco cheio

A visualização Full Disk Space Diagnosis mostra quais tipos de arquivo estão consumindo armazenamento e como seus tamanhos mudam ao longo do tempo. As seguintes categorias de armazenamento são rastreadas:

• Arquivos de dados (user_data_size): Use a Space Analysis para identificar o uso de espaço por banco de dados e tabela, e então escale horizontalmente ou exclua dados desnecessários. Consulte Solutions for a full instance caused by data files.

• Arquivos temporários (temp_file_size): Gerados durante operações de ordenação, agrupamento e junção SQL, e como arquivos de cache de binary log antes do commit de transações grandes. Consulte Resolve full instance storage caused by temporary files.

• Binary logs (binlog_size): Transações grandes podem gerar binary logs rapidamente. Se seus serviços assinarem os binary logs da instância, os logs podem não ser limpos prontamente. Consulte Resolve full instance storage caused by binary log files.

• Undo logs (undo_log_size): Consultas de longa duração impedem a purga dos undo logs. Verifique se há consultas em execução que não foram concluídas.

  Nota

  No MySQL 5.6 e versões anteriores, os undo logs não possuem tablespace separado.

• Slow log (slowlog_size): Execute o comando truncate fora do horário de pico para limpar o slow log caso ele consuma espaço excessivo.

  Nota

  O suporte ao comando truncate foi adicionado no MySQL 5.7 versão 20210630 e no MySQL 8.0 versão 20210930.

• General logs (general_log_size): Tamanho combinado dos logs de erro, Performance Agent e recuperação da instância. Esse valor geralmente é estável e inferior a 1 GB. Se exceder significativamente esse limiar, envie um ticket para entrar em contato com a equipe do produto.

  Nota

  general_log_size representa dados gerados periodicamente pelo kernel do MySQL — não o tamanho do arquivo general_log do MySQL.

Diagnóstico de oscilação de CPU

A visualização CPU Jitter Diagnosis ajuda a identificar por que a utilização da CPU flutua. Acompanhe estas métricas:

Métricas de negócio:

• Page Request: As solicitações ao Buffer Pool normalmente flutuam em sincronia com a utilização da CPU.

• Rows Processed: Compare com a utilização da CPU para determinar se mudanças no volume de linhas se correlacionam com picos de CPU.

• Queries: Identifique os tipos de instruções SQL executadas durante as mudanças na utilização da CPU.

Conexões:

• Thread Running: Alta concorrência eleva a utilização da CPU. Acúmulo de MDL e row locks também podem causar acúmulo de conexões, aumentando a carga da CPU.

Causas comuns e próximos passos:

• Se Page Request ou Rows Processed mudou quando a CPU teve pico, arraste para selecionar o intervalo de tempo afetado e clique em Diagnose para obter uma análise detalhada da causa raiz.

• Se as conexões ativas aumentaram, investigue pelo lado da aplicação para determinar o que causou o aumento.

Diagnóstico de transações grandes

A visualização Large Transaction Recognition Diagnosis ajuda a identificar transações grandes e seu impacto. Três métricas principais sinalizam uma transação grande:

Rows Processed, Logical Page Write e Queries per Second indicam o tipo de transação. Por exemplo, poucas consultas combinadas com alta contagem de exclusão de linhas apontam para uma operação DELETE grande.

Como transações grandes afetam a instância:

1. Enquanto a transação grande executa, o tablespace temporário (cache de binary log) aumenta gradualmente e depois estabiliza.

2. Quando o tablespace temporário estabiliza, o espaço de binary log aumenta. Como as gravações de binary log são globalmente seriais, outras transações são bloqueadas e as conexões se acumulam.

3. Em instâncias High-availability Edition, as instruções de sondagem do componente HA nas instâncias primária e secundária também são bloqueadas, ocorrendo failover entre primária e secundária.

Para evitar esses problemas, divida transações grandes em menores. Para instruções DELETE, adicione uma cláusula WHERE que limite quantas linhas são excluídas por operação, convertendo uma única exclusão grande em múltiplas exclusões menores.