Se os servidores da sua aplicação apresentarem alta utilização de CPU ou consumo elevado de memória e for necessário identificar os métodos responsáveis, use um gráfico de chama para apontar exatamente os caminhos de chamada que mais consomem recursos. O perfilamento contínuo do Application Real-Time Monitoring Service (ARMS) gera gráficos de chama para analisar a causa raiz de gargalos de desempenho, como alta utilização de CPU, consumo excessivo de memória e picos de latência.
Como ler um gráfico de chama
Um gráfico de chama visualiza dados amostrados da pilha de chamadas em um único gráfico. Cada caixa representa uma função nessa pilha.
Os dois eixos codificam informações diferentes:
|
Eixo |
Representa |
Detalhes |
|
Eixo X |
Proporção do uso total de recursos |
Caixas mais largas indicam maior consumo de CPU ou memória. O eixo X não representa a progressão do tempo. As funções são ordenadas alfabeticamente para mesclar frames de pilha idênticos. Isso maximiza a consolidação dos frames e destaca os caminhos de chamada mais significativos. |
|
Eixo Y |
Profundidade da pilha de chamadas |
A base da pilha contém as funções de ponto de entrada. O topo da pilha contém as funções filhas chamadas mais recentemente. |
Na ciência da computação, uma pilha é um tipo de dado abstrato que funciona como uma coleção de elementos com duas operações principais: Push (insere elementos na pilha) e Pop (remove elementos da pilha). Em um gráfico de chama, quanto mais tempo uma função leva para executar, mais tempo sua função pai consome e mais larga sua caixa aparece. Compare gráficos de chama em diferentes momentos para diagnosticar e tratar gargalos de desempenho com eficiência.
Tempo próprio vs. tempo total
A largura da caixa de uma função representa seu tempo total: o tempo gasto na própria função somado ao de todas as funções que ela chama. A parte da caixa sem nenhuma função filha diretamente abaixo representa o tempo próprio da função, ou seja, o tempo gasto executando seu próprio código, excluindo as chamadas para outras funções.
Ao analisar gargalos, concentre-se nas funções com alto tempo próprio. Uma caixa larga nem sempre indica uma função lenta; ela pode simplesmente chamar muitas funções filhas.
Gráfico de chama vs. gráfico de estalactite
Os gráficos de chama possuem duas orientações de layout que exibem os mesmos dados:
|
Layout |
Topo da pilha |
Base da pilha |
Direção da análise |
|
Gráfico de chama |
Parte superior do gráfico |
Parte inferior do gráfico |
De baixo para cima |
|
Gráfico de estalactite |
Parte inferior do gráfico |
Parte superior do gráfico |
De cima para baixo |
Gráfico de chama
Gráfico de estalactite
Identifique um gargalo em três etapas
|
Etapa |
Ação |
Motivo |
|
1 |
Determine o layout. Identifique se o gráfico é de chama ou de estalactite e localize o topo da pilha. |
As funções causadoras de gargalo surgem no topo da pilha. |
|
2 |
Encontre caixas largas no topo da pilha. Caixas largas nessa posição indicam funções que consomem grande proporção de recursos. |
Largura = proporção do uso total de recursos. |
|
3 |
Rastreie até o código da sua aplicação. A partir da caixa larga no topo da pilha, percorra a cadeia de chamadas até encontrar o primeiro método definido pela sua aplicação, e não um método de biblioteca ou framework. |
Funções de biblioteca não são otimizáveis diretamente. Investigue o primeiro método definido pela aplicação na cadeia. |
Exemplo: identificar um gargalo de CPU
O gráfico de estalactite a seguir mostra alto uso de CPU. Para reproduzir esta análise, ative o recurso de perfilamento contínuo na sua aplicação.
Etapa 1: determinar o layout
Este é um gráfico de estalactite: a base da pilha está na parte superior e o topo da pilha está na parte inferior. Analise de baixo para cima.
Etapa 2: encontrar caixas largas no topo da pilha
O método java.util.LinkedList.node(int), no lado direito do topo da pilha, possui uma caixa larga, o que indica alto consumo de recursos.
Etapa 3: rastrear até o código da aplicação
java.util.LinkedList.node(int) é uma função de biblioteca do Java Development Kit (JDK), não código da aplicação. Rastreie para cima na cadeia de chamadas:
|
Método |
Tipo |
Ação |
|
|
Função de biblioteca JDK |
Continue o rastreamento. |
|
|
Função de biblioteca JDK |
Continue o rastreamento. |
|
|
Código da aplicação |
Primeiro método definido pela aplicação encontrado. |
Resultado: HotSpotAction.readFile() consome 3,89 segundos, o que representa 76,06% da pilha. Este método é o principal gargalo. Revise sua implementação para determinar se é possível otimizar o padrão de chamadas.
Gargalo secundário
O método java.net.SocketInputStream, no canto inferior esquerdo do gráfico, leva a outro método da aplicação: com.alibaba.cloud.pressure.memory.HotSpotAction.invokeAPI, que responde por aproximadamente 23% da pilha.
Próximos passos
Diagnostique problemas específicos de desempenho:
Use o recurso de diagnóstico de código para diagnosticar traces lentos em aplicações Java
Use o recurso de diagnóstico de CPU para diagnosticar alta utilização de CPU
Use o recurso de diagnóstico de memória para diagnosticar alto uso de memória heap
Solucione problemas de perfilamento contínuo: