Application Real-Time Monitoring Service:Perguntas frequentes

Ative o Continuous Profiling não gera dados

É normal o uso de memória do monitoramento de heap diferir do uso detectado pelos hot spots de memória no continuous profiling?

O Continuous Profiling registra apenas alocações de memória heap dentro de um período especificado, e não o uso total de memória do processo.

Diagnósticos de CPU têm dados, mas diagnósticos de memória não

Esse problema geralmente ocorre com versões do agente 3.1.4 e posteriores.

A ausência de dados nos diagnósticos de memória normalmente indica o uso de uma imagem base Alpine. Imagens base Alpine removem os símbolos de depuração do JDK para reduzir seu tamanho, o que impede o funcionamento correto do continuous profiling. Para resolver, instale os símbolos de depuração do JDK na sua imagem ou utilize uma imagem base que não seja Alpine. Observe que algumas versões do JDK não possuem pacotes de símbolos de depuração correspondentes, o que pode impedir uma instalação bem-sucedida.

Por que não há dados para hot spots de código ou os dados não atendem às expectativas?

1. O profiling de hot spots não é suportado para aplicações que utilizam virtual threads ou tecnologias similares no JDK, incluindo o Alibaba Dragonwell JDK.

2. O protocolo SkyWalking não suporta o recurso de hot spots de código. Confirme o tipo de protocolo nos detalhes do span de um trace.

3. O recurso de hot spots de código exige a versão 3.1.4 ou posterior do agente. Versões anteriores não oferecem suporte a esse recurso.

4. Versões do agente anteriores à 4.2.1 suportam apenas chamadas síncronas e podem não coletar dados completos. Dados de chamadas assíncronas podem estar ausentes. Por exemplo, o uso de Spring Cloud Gateway, Undertow ou Lettuce pode causar troca de threads assíncronas, levando a uma coleta de dados imprecisa. As versões 4.2.1 e posteriores incluem otimizações para esses cenários. Recomendamos atualizar o agente para a versão mais recente.

5. O recurso de hot spots de código é suportado apenas para traces amostrados a uma taxa fixa. Não há suporte para traces coletados com taxas de amostragem não fixas, como amostragem de erros (s9) ou amostragem de lentidão (s10), pois isso causaria alta sobrecarga de desempenho. Esses tipos de amostragem são acionados somente após a conclusão do trace. Utilize verificar o campo sample.reason nos atributos do span para determinar o tipo de amostragem.

   Para traces coletados com taxa de amostragem não fixa, acesse a página Trace Analysis. Use o parâmetro Traces with Code Hotspots para filtrar traces que contenham hot spots de código e diagnosticar problemas.

6. Ao usar a versão 4.2.1 ou posterior do agente, o tempo de execução coletado pode ser muito inferior ao tempo registrado pelo span externo. Isso pode acontecer se sua aplicação utilizar um framework de I/O assíncrono e não bloqueante (NIO), como o Spring Cloud Gateway. Quando esses frameworks recebem uma requisição de um service upstream ou enviam uma requisição para um service downstream, eles não bloqueiam a thread se os dados não estiverem prontos. Em vez disso, a thread retorna imediatamente e pode executar outras tarefas, melhorando a utilização das threads. Como a thread não fica bloqueada aguardando I/O, o gargalo de desempenho não está na aplicação atual. Nesse caso, o tempo coletado para o hot spot de código pode ser muito menor que a duração do span. Verifique se há gargalos no processamento de requisições da aplicação upstream ou downstream, ou na rede.

Qual é a sobrecarga de desempenho do continuous profiling?

• Testes de desempenho indicam a seguinte sobrecarga para o continuous profiling: Em um cenário com 500 Transações Por Segundo (TPS) e todos os recursos ativados em uma aplicação Spring Web padrão, a sobrecarga de CPU aumenta aproximadamente 5% e a sobrecarga de memória off-heap aumenta cerca de 50 MB. O aumento na coleta de lixo (GC) e na latência de requisição não é significativo.

• Em casos extremos, o profiling de hot spots de memória não possui limite de taxa. Se uma aplicação alocar memória com muita frequência, poderá gerar um alto volume de eventos, como dezenas de milhares por minuto. Isso pode afetar a latência P99. Desative o profiling de memória para resolver esse problema.

  Esse problema foi corrigido na versão 4.1.10. Você pode atualizar o agente para a versão 4.1.10 ou posterior.

Threads relacionadas a JFR na aplicação

• O recurso de continuous profiling cria threads do JDK Flight Recorder (JFR). Essas threads são encontradas principalmente em versões do agente anteriores à 4.1.10. As versões 4.1.10 e posteriores não criam threads JFR.

• Essas threads não causam gargalos de desempenho na aplicação.

• Se você desativar dinamicamente a opção de continuous profiling, a thread não será destruída imediatamente. Ela desaparece apenas após a reinicialização da aplicação.

Continuous profiling durante a inicialização da aplicação

O continuous profiling pode tornar a inicialização da aplicação mais lenta. Isso ocorre se o JDK não tiver símbolos de depuração e o Classloader carregar muitos métodos. Após a inicialização, não há impacto no desempenho de execução da aplicação.

Esse problema foi corrigido na versão 4.2.1 do agente. Você pode atualizar o agente para esta versão a fim de resolver o problema.

Por que a memória total no gráfico de chama excede o limite de memória configurado?

Os dados no continuous profiling não estão diretamente relacionados à configuração de memória do host. Eles mostram a quantidade total de memória heap alocada durante o período de análise. Devido à coleta de lixo, é normal que esse valor seja maior que a memória configurada no host.

Falha de anexação no OpenJ9 JDK

O continuous profiling do ARMS não suporta IBM OpenJ9. O uso desse JDK pode causar falha na integração e gerar erros. Recomendamos o uso de OpenJDK ou Oracle JDK.

Dados de hot spots de código em spans estão incompletos

Hot spots de código são identificados amostrando as pilhas de métodos das threads em um trace em intervalos definidos. Se um método estiver ausente no gráfico de chama de hot spots de código, pode ser porque seu tempo de execução é inferior a 500 ms. Métodos com tempos de execução tão curtos podem não ser capturados pelo processo de amostragem. Isso não afeta o diagnóstico de traces lentos, pois métodos de curta duração não são considerados gargalos de desempenho.

Por que o gráfico de chama contém pilhas .GC_active?

.GC_active indica que a coleta de lixo (GC) estava ativa durante a coleta de dados para o gráfico de chama. O processo de GC pausou todas as threads de negócios Java em um evento conhecido como "Stop-the-World". Se .GC_active aparecer em um hot spot de código, significa que uma pausa de GC contribuiu para a latência da requisição.

Por que o gráfico de chama contém entradas "unknown"?

Em um sistema operacional Alpine, se o JDK não tiver símbolos de depuração e o classloader carregar muitos métodos, ativar o continuous profiling pode tornar a aplicação lenta ou causar timeout. Para evitar isso, as versões 4.2.1 e posteriores do agente monitoram o tempo de carregamento. O limiar padrão é 150 ms. Se o carregamento exceder esse tempo, o agente interrompe algumas etapas demoradas. Isso pode impedir que alguns símbolos de método sejam analisados corretamente, resultando em entradas "unknown". Ajuste esse limiar para mitigar o problema. Por exemplo, defina a variável de ambiente AP_JMID_TIME_LIMIT como 500 (milissegundos): export AP_JMID_TIME_LIMIT=500.

Por que o gráfico de chama contém entradas .no_Java_frame?

Isso geralmente acontece ao usar uma imagem base Alpine. O Alpine remove os símbolos de depuração do JDK para reduzir o tamanho da imagem. Isso impede que o sistema identifique nomes de funções nas pilhas de métodos de threads C++ dentro do JDK. Essas pilhas são então exibidas como .no_Java_frame. Elas representam principalmente informações de threads não Java, como da VM Thread ou da thread do compilador Just-In-Time (JIT). Se a proporção de entradas .no_Java_frame for baixa, ignore-as. Concentre-se nas outras pilhas de métodos Java para análise de desempenho. Se a proporção for alta, instale símbolos de depuração para o JDK na sua imagem base ou mude para uma imagem base que não seja Alpine. Note que algumas versões do JDK não possuem pacotes de símbolos de depuração correspondentes, o que pode impedir a instalação.

Por que o item "other" aparece no gráfico de chama?

Saída de log: parse lib sigsegv handler installed

Como resolver o erro "No access to perf events" causado por restrições de perf_event_open?

[ERROR] Failed to execute 'start,jfr=0,event=cpu,interval=11ms,alloc=512k,file=/tmp/cpc-async-profiler-7729534006755968198.jfr'
[ERROR] Failed to start Continuous Profile Collector
java.lang.RuntimeException: java.lang.IllegalStateException: No access to perf events. Try --fdtransfer or --all-user option or 'sysctl kernel.perf_event_paranoid=1'

Como resolver o erro "No AllocTracer symbols found. Are JDK debug symbols installed?"?

Esse erro, ou a falta de dados, pode ocorrer se seu processo Java for executado em um contêiner que usa uma imagem base Alpine. Imagens base Alpine removem os símbolos de depuração do JDK para reduzir seu tamanho, o que impede o funcionamento correto do continuous profiling. Para resolver esse problema, consulte as soluções para falha na coleta de hot spots de memória devido à falta de símbolos de depuração.

Como resolver o erro "perf_event mmap failed..."?

Outras operações

from Alpine:3.9
RUN apk add openjdk8