GUJ Discussões   :   últimos tópicos   |   categorias   |   GUJ Respostas

Analise de garbage collector (Base CA-Introscope )

java
Tags: #<Tag:0x00007fd732109eb8>

#1

Fala Galera beleza? Tudo Legal!? Estou precisando fazer uma analise de GC, poderiam me ajudar com isso?
Abaixo segue prints extraídos do CA-Introscope, o que eu preciso é entender melhor para gerar um relatório de analise, com base nesses gráficos abaixo em qual conclusão vocês chegam? pode me ajudar com alguma sugestão?

Com Base nos gráficos podemos afirmar que não esta havendo coleta?

Como funciona todo esse ciclo de reciclagem;
PS Suvivor Space -
PS Old Gen -
PS Eden Space -
PS Perm Gen -


#2

segue segunda imagem (só posso colocar uma imagem por post!)


#3

Ola bom dia,
uma breve explicação :
PS Eden Space - todo objeto criado é jogado para este local do heap

PS Suvivor Space - após a primeira passada do GC os objetos sobreviventes são alocados nesta área do heap

PS Old Gen - após o GC passar uma certa quantia de vezes no “survivor space” os objetos são copiados para esta área

PS Perm Gen - Aqui é onde fica todo o core do java, como classes nativas o proprio rt.jar é carregado aqui, o pool de string, os classloaders e as classes do programa. --> o GC passa nesta parte mas com pouca frequencia

–Agora vamos para a analise, primeiramente existem poucas informações para podermos fazer uma analise assertiva, mas olhando por cima tive duas conclusões:

1° Uma aplicação é de alto consumo de memoria, por exemplo, ela guarda muita coisa em cache, carrega objetos grandes em memoria e utiliza em toda a aplicação, mantendo sempre uma referencia para o mesmo, esse tipo de coisa.

2° existe um leak de memoria, algumas referencias não estão sendo liberadas, carregando muitas coisas na memoria e não permitindo que o GC colete estes objetos.

no gráfico podemos observar que existe momentos em que a memoria é liberada, mas isso talvez seja devido a algum fator externo a aplicação.

Mas como eu disse são palpites, pois não podemos ter ctz com apenas essas informações, eu aconselho vc utilizar um profiling também, para poder ver quais as classes e métodos estão consumindo tantos recursos assim, para poder efetuar uma analise de fonte, assim poderia ter informações mais concretas

flw :slight_smile:


#4

Oi! Victor_Dourigam!
Muito obrigada pelas dicas!
Na questão do profiling é um software especifico :unamused:

Att:blush:


#5

kkkkkkk para uma analise legal seria interessante ter a telemetria deste profiling, mas qualquer outra duvida ou mais informações que vc obter posta aqui para ajudarmos(ou tentar pelo menos kkkkkk)

flw e boa sorte :smile_cat:


#6

kkk verdade! Eu juro que li outra coisa! Vou tentar pegar mais informações dessa aplicação!

Att


#7

pra ajudar na analise, vc pode mencionar qual GC e quais parametros vc esta usando?

pq hoje em dia a JVM tem diferentes collectors e vc ainda pode fazer um fine tunning do mesmo.

o que eu lembro de +10 anos atras é que se vc criasse poucos objetos GRANDES era capaz deles nunca serem coletados.

vc sabe a natureza desse programa sendo executado? faz uso intensivo de Threads, I/O ou recursão?


#8

Olá! Pessoal ! Muito Obrigada! Pelo Retorno de todos…
então é o seguinte Eu não posso passar muitas informações, mais esse caso aqui… é di uma empresa Gigante … Gigante mesmo…mais pretendo sim colocar mais informações! Porque eu estou trazendo um caso real…


#9

Oi! Peczenyj, eu estou levantando mais detalhes dessa aplicação ai vou postando aqui… o que eu consigo ter é a visão do Introscope…
Essa aplicação tem muitas instancias e pelo que já esse problema com o GC se repete em todas…


#10

Coletei Hj essas informações:
1174 Threads 1160 Waiting 0 Blocked 14 Running, isso foi hj, o gráfico é de pelomenos 7 dias atras
Eu estou com o arquivo com todas essas threads. Mais pra colocar aqui é muita coisa.


#11

que mal pergunte, esse é o seu trabalho e vc não sabe analisar isso, ou vc precisa de uma ajuda pontual/teorica pra analisar os dados?


#12

Peczeny, é um pouco dos dois, mais o que eu preciso mesmo é focar na parte de analise de dados. Eu estou precisando mesmo é analisar essas 1117 threads…