ApsaraDB RDS:Visualize 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 Visualizar Eventos de Desempenho, 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 de tempo.

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 seu resultado de 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 Visualizações de diagnóstico.

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 na memória.

Como eventos de OOM frequentemente encerram os processos que causaram o pico, identificar a instrução SQL exata após o ocorrido é 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, você possa 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 Análise de Espaço para identificar o uso de espaço por banco de dados e tabela, e então escale horizontalmente ou exclua dados desnecessários. Consulte Soluções para instância cheia causada por arquivos de dados.

• 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 grandes transações. Consulte Resolver armazenamento cheio da instância causado por arquivos temporários.

• Binary logs (binlog_size): Grandes transações podem gerar binary logs rapidamente. Se seus services assinarem os binary logs da instância, os logs podem não ser limpos prontamente. Consulte Resolver armazenamento cheio da instância causado por arquivos de binary log.

• Undo logs (undo_log_size): Consultas de longa duração impedem que os undo logs sejam purgados. 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): O 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, abra um ticket para entrar em contato com a equipe do product.

  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 impulsionou o aumento de conexões.

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.