Quando o uso de CPU apresenta picos em produção, identificar os métodos exatos responsáveis apenas por métricas pode ser difícil. O Application Real-Time Monitoring Service (ARMS) perfila continuamente as threads ativas de CPU ao capturar snapshots de pilha no nível de método em intervalos regulares. Esses snapshots são agregados em gráficos de chama e estatísticas no nível de método, permitindo identificar com precisão quais caminhos de código consomem mais ciclos de CPU.
Ative o diagnóstico de CPU adiciona uma sobrecarga de aproximadamente 5% de CPU. Certifique-se de que suas instâncias tenham capacidade suficiente antes de ativar esse recurso.
Como funcionam os gráficos de chama
O ARMS agrega snapshots de pilha amostrados em um gráfico de chama que codifica duas dimensões:
|
Dimensão |
Significado |
Como interpretar |
|
Largura (eixo X) |
Proporção do tempo total de CPU consumido por um método |
Caixas mais largas indicam maior consumo de CPU |
|
Profundidade (eixo Y) |
Hierarquia de chamadas — a base é o ponto de entrada e o topo é o método folha |
Consulte o topo do gráfico para visualizar os métodos onde os ciclos de CPU são efetivamente gastos |
A posição horizontal não representa a progressão temporal. Dois métodos posicionados lado a lado não foram necessariamente executados em sequência.
Tempo próprio vs. tempo total
Duas métricas ajudam a distinguir entre métodos individualmente custosos e métodos que contribuem para o alto uso de CPU por meio de seus filhos:
|
Métrica |
Definição |
Quando usar |
|
Self |
Tempo ou recursos que um método consome dentro da pilha, excluindo o tempo ou recursos consumidos pelos métodos filhos |
Identificar métodos individualmente custosos |
|
Total |
Tempo ou recursos que um método consome, incluindo o tempo ou recursos consumidos por todos os métodos filhos |
Encontrar caminhos de chamada que mais contribuem para o tempo total de CPU |
Tempo próprio = Tempo total - soma do tempo total dos filhos. Por exemplo, se um método apresenta 309 ms de Total e seu único filho apresenta 112 ms de Total, o tempo próprio do pai é 197 ms (309 - 112).
Ative diagnóstico de CPU
Faça login no console do ARMS. No painel de navegação à esquerda, escolha Application Monitoring > Application List.
-
Na página Application List, selecione uma região na barra de navegação superior e clique em no nome da aplicação.
Os ícones na coluna Language indicam a linguagem da aplicação:
Java 
Go 
Python Hífen ( - ): aplicação monitorada por meio do Managed service for OpenTelemetry. No painel de navegação à esquerda, clique em Application Settings. Clique em na aba Custom Configuration.
Na seção Continuous profiling, ative Main switch e CPU hotspot e especifique o endereço IP de uma instância da aplicação ou os blocos CIDR para múltiplas instâncias.
Clique em Save.
A alteração entra em vigor imediatamente — não é necessário reiniciar a aplicação.
Identificar o método causador do problema
O exemplo a seguir utiliza um método Java que execute uma espera ativa por 500 milissegundos para simular consumo sustentado de CPU:
public class CPUPressure {
// Busy-wait loop that holds the CPU for 500 ms per call
public void runBusiness() {
long start = System.currentTimeMillis(), period = 0;
while (period <= 500L) {
period = System.currentTimeMillis() - start;
}
}
}Etapa 1: Abrir a visualização de perfilamento
Faça login no console do ARMS. No painel de navegação à esquerda, escolha Application Monitoring > Application List.
-
Na página Application List, selecione uma região na barra de navegação superior e clique em no nome da aplicação.
Os ícones na coluna Language indicam a linguagem da aplicação:
Java Go Python Hífen ( - ): aplicação monitorada por meio do Managed service for OpenTelemetry. No painel de navegação à esquerda, clique em Continuous profiling. Selecione a instância de destino e um intervalo de tempo.
-
Na aba Single View, consulte os dados e visualize os resultados de agregação.
Três tipos de perfilamento estão disponíveis: CPU Time: núcleos de CPU consumidos por cada método. Allocated Memory: bytes de memória alocados. Allocations: número de chamadas de alocação de memória — útil para identificar métodos com alocações frequentes.
Etapa 2: Localizar o método custoso
-
Clique em Aggregation & Analysis. Defina Profiling Type como CPU Time. O painel esquerdo lista todos os métodos envolvidos nas pilhas de chamadas amostradas. O painel direito exibe o gráfico de chama.
-
Ordene a coluna Self em ordem crescente. Encontre e clique em no método com o maior valor de Self. Neste exemplo,
java.lang.System.currentTimeMillis()aparece no topo. Ao clicar nele, a caixa correspondente no gráfico de chama será destacada.
Confirme no gráfico de chama que
currentTimeMillis()possui a caixa mais larga no topo da pilha, indicando que consumiu a maior quantidade de tempo próprio ou recursos.
Etapa 3: Rastrear até o código da aplicação
Como currentTimeMillis() é um método da biblioteca JDK, examine um nível abaixo na pilha de chamadas para encontrar o método da aplicação que o invoca: com.alibaba.cloud.pressure.memory.CPUPressure.runBusiness().
Esse método consumiu 28,63 segundos em uma janela de 1 minuto, representando 91,44% do tempo total de CPU. Isso corresponde ao comportamento esperado — runBusiness() execute uma espera ativa de 500 ms a cada invocação, dominando o uso de CPU sob carga.