Application Real-Time Monitoring Service:FAQs

Por que não há dados na página após ativar o continuous profiling?

Os percentuais de uso de memória exibidos no monitoramento de heap memory diferem daqueles detectados em um determinado período no continuous profiling. Isso é normal?

O continuous profiling registra apenas a alocação de heap memory durante um período especificado, e não a quantidade total de memória ocupada pelo processo atual. Portanto, é normal observar diferenças entre esses dois conjuntos de dados.

Por que o diagnóstico de CPU exibe dados enquanto o diagnóstico de memória não mostra nenhum?

Problema

A ausência de dados de diagnóstico de memória geralmente ocorre com agentes ARMS V3.1.4 ou posteriores em ambientes conteinerizados que utilizam imagens base Alpine. O Alpine remove os símbolos de depuração do JDK para reduzir o tamanho da imagem, desativando as capacidades de continuous profiling.

Solução

1. Verifique se o JDK no ambiente contém símbolos de depuração.

2. Caso não contenha, instale-os para o JDK em suas imagens (a instalação pode falhar em algumas versões do JDK sem os pacotes de símbolos de depuração) ou utilize imagens base que não sejam Alpine.

Por que não há dados para code hotspots? Por que os dados de code hotspot não atendem às expectativas?

1. A análise de hotspots de memória não está disponível para aplicações que usam virtual threads ou tecnologias semelhantes em seus JDKs (incluindo o Alibaba Dragonwell JDK).

2. Atualmente, o protocolo SkyWalking não oferece suporte ao recurso de code hotspot. Verifique o tipo de protocolo nos detalhes do span do trace.

3. O recurso de code hotspot exige um agente ARMS V3.1.4 ou posterior.

4. Agentes ARMS anteriores à versão V4.2.1 suportam apenas invocações síncronas e podem apresentar coleta de dados incompleta. Invocações assíncronas podem resultar em dados ausentes ou imprecisos. Por exemplo, ao usar frameworks como Spring Cloud Gateway, Undertow e Lettuce, a troca de threads assíncronas pode levar a uma coleta de dados imprecisa. Os agentes V4.2.1 e posteriores foram otimizados para resolver esses problemas. Atualize seu agente para obter o melhor desempenho.

5. Code hotspots são suportados apenas para traces amostrados com uma taxa de amostragem fixa. A coleta de traces usando uma taxa de amostragem não fixa pode gerar sobrecarga significativa de desempenho, como amostragem incorreta (s9) e amostragem lenta (s10) acionadas após a conclusão do trace (você pode verificar o campo sample.reason nos atributos do span). Traces coletados com taxa de amostragem não fixa atualmente não suportam code hotspots.

   Para traces coletados com taxa de amostragem não fixa, recomendamos filtrar aqueles que contêm code hotspots usando o parâmetro Traces with Hotspot Code na página Trace Explorer para diagnosticar problemas.

   

6. Se você usar um agente V4.2.1 ou posterior, mas notar que a duração coletada é significativamente menor que a duração registrada pelo span externo, isso pode indicar que sua aplicação utiliza um framework NIO assíncrono e não bloqueante (por exemplo, Spring Cloud Gateway). Esses frameworks, ao enviar solicitações para serviços downstream, não bloqueiam threads se os dados downstream não estiverem prontos; em vez disso, retornam imediatamente, permitindo que as threads executem outras tarefas e aumentando a utilização das threads. Como nenhuma execução real de thread ocorre nesse cenário, o gargalo de desempenho pode não estar na aplicação atual. Nesses casos, a duração da coleta de code hotspot pode ser muito inferior à duração do span. Concentre-se em investigar se existem gargalos no processamento de solicitações da aplicação downstream ou na latência de rede.

Qual é a sobrecarga de desempenho do continuous profiling?

• Testes realizados com o continuous profiling mostram que, em um cenário de 500 TPS com todos os recursos ativados em uma aplicação Spring Web típica, a sobrecarga de CPU aumenta cerca de 5%, o uso de memória off-heap cresce aproximadamente 50 MB, e não há aumentos significativos na latência de GC nem de requisições.

• Em casos extremos, como a análise de hotspots de memória ainda não implementa limitação de taxa, se a aplicação alocar memória frequentemente, poderá gerar um grande volume de eventos relacionados (como dezenas de milhares por minuto), impactando potencialmente a latência P99. Desative temporariamente o memory profiling para resolver esse problema.

  Essa questão foi corrigida na versão V4.1.10. Você pode atualizar o agente diretamente para a versão V4.1.10 ou posterior.

Por que existem threads relacionadas a JFR na aplicação?

• O recurso de continuous profiling gera threads JFR. Essas threads existem principalmente no agente ARMS V4.1.10 e deixarão de ser introduzidas ativamente na versão V4.1.10 ou posterior.

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

• Após desativar dinamicamente o continuous profiling, as threads não serão destruídas imediatamente, desaparecendo somente depois que a aplicação for reiniciada.

O que fazer se o continuous profiling afetar o tempo de inicialização da aplicação?

Em aplicações com continuous profiling ativado, se o JDK não possuir símbolos de depuração e o class loader carregar muitos métodos, a velocidade de inicialização pode diminuir significativamente. No entanto, após a conclusão da inicialização, não há impacto no desempenho em tempo de execução.

Esse problema foi corrigido na versão V4.2.1 e não afetará mais a inicialização da aplicação. Atualize o agente para a versão V4.2.1 ou posterior.

Por que a memória total no flame graph excede o limite de memória realmente configurado?

Os dados exibidos no continuous profiling não estão diretamente vinculados à configuração da máquina. Eles representam o tamanho da heap memory alocada durante o período analisado. Devido à coleta de lixo (garbage collection), é esperado que a memória exibida possa ultrapassar a memória real configurada na máquina.

O que fazer se a integração com OpenJ9 JDK falhar?

O continuous profiling atualmente não suporta Eclipse OpenJ9 (anteriormente conhecido como IBM J9). A integração com esse JDK pode falhar e gerar erros. Recomendamos o uso de OpenJDK ou Oracle JDK.

O que fazer se os dados de code hotspot nos Spans estiverem incompletos?

Os code hotspots são coletados amostrando pilhas de métodos de threads em traces em intervalos regulares. Para métodos ausentes no flame graph de code hotspot, verifique se o tempo de execução deles é inferior a 500 milissegundos. Se for, eles podem não ter sido capturados. Isso não afeta o diagnóstico de traces lentos relacionados, pois métodos com tempos de execução curtos dificilmente serão gargalos de desempenho.

Por que o flame graph contém pilhas .GC_active?

.GC_active indica que, durante a coleta de dados do flame graph, a aplicação foi afetada pelo processo Stop-the-World da coleta de lixo (no qual todas as threads de negócios Java são pausadas). Isso causa a suspensão das threads de negócios relacionadas. Se .GC_active aparecer nos code hotspots, significa que parte da latência da requisição foi causada por pausas de GC.

Por que o flame graph contém entradas .no_Java_frame?

Isso geralmente ocorre devido ao uso da imagem base Alpine. Para reduzir o tamanho da imagem, o Alpine remove os símbolos de depuração do JDK, impedindo o reconhecimento de nomes de funções nas pilhas de métodos de threads C++ dentro do JDK. Como resultado, essas pilhas são exibidas como .no_Java_frame. Visto que essas pilhas representam principalmente informações de execução de threads não Java (como threads de VM ou threads do compilador JIT), você pode ignorá-las se sua proporção for baixa e focar em outras pilhas de métodos Java para análise de desempenho. Se as entradas .no_Java_frame representarem uma proporção alta, considere instalar símbolos de depuração para o JDK na imagem base ou mudar para 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 a instalação.

Por que o item "other" aparece no flame graph?

A saída de log "parse lib sigsegv handler installed" afeta a aplicação em tempo de execução?

Como resolver o erro "No access to perf events" causado por restrições em 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 de profiling podem ocorrer em processos Java executados em ambientes de contêiner quando imagens base Alpine são utilizadas. Tais imagens removem os símbolos de depuração do JDK para reduzir o tamanho da imagem, prejudicando a funcionalidade de continuous profiling. Nesse caso, atualize o JDK, altere as imagens base ou use o Alpine Linux e JDK padrão conforme necessário.

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

Outros

from Alpine:3.9
RUN apk add openjdk8