VRaptor + Consumo de Memória

[tiago.javaman]

Olá a todos.

Instalei o JProfiler para monitorar minha aplicação desenvolvida com VRaptor, buscando melhorar o consumo de memória.

Estou achando estranho a quantidade de objetos 'char[]' com valores vazios e etc, chegando aos incríveis 200mb.

Quando visualizo os objetos eles aparecem a maioria em branco.

Quais programas vcs utilizam pra monitorar/identificar o consumo, alguém tem alguma dica de como identifico isso ?

Segue a imagem anexada.

[tiago.javaman]

Talvez esse não seja o grupo adequado, mas gostaria de compartilhar com vcs.

Recentemente contratando uma hospedagem de 450mb, notei que minha aplicação estava no consumindo mais de 400mb.

Instalei o JProfiler, e também usei agora o VisualVM, fui enxugando a minha aplicação e o que mais me impressionou foi o "jasperreport".

Somente ao levantar a aplicação com jasper a diferença é mais de 150mb, sim 150mb só para levantar a aplicação.

Para confirmar isso, baixei o projeto vraptor-blank-project, configurei e levantei ele com tomcat, monitorando durante 05 minutos.

Depois levantei outra instancia do mesmo projeto só que com agora com a dependência do jasper, ou melhor com o plugin mesmo "vraptor-jasperreport".

Os resultados estão em anexo, mas a diferença é absurda, sem falar os 'picos' dentro de segundos.

Enfim, por mais que o projeto não esteja carregando nenhum relatório no momento, é normal toda essa memória sendo usada dessa forma?

Sem mais.

[tiago.javaman]

[Carlos Spohr]

Tiago,

Tu diz de ter apenas as deps do jasper para processar os jasper solicitados, ou ele rodando como um server (processo a parte)?

Acredito que o jasper tenha alguns problemas sérios de memória, pq tenho uma aplicação que roda como serviço e a história é a mesma quanto a consumo de memória....as vezes percebo que do 'nada' o serviço para pq atingiu um heap mesmo sem ter disparado nenhuma operação.

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para caelum-...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/caelum-vraptor.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Atenciosamente,
Carlos Alberto Junior Spohr Poletto

carlos.inf.br

[tiago.javaman]

Carlos, apenas as dependência no pow já é o suficiente pra notar a diferença de memória.

O que me preocupa, pois mesmo não invocando nenhum relatório ele parece estar esbanjando memória.

[Carlos Spohr]

Então

Será que não pode ser o próprio CDI (ou outro alguém) que faça um deep scan nas classes pra deixá-las 'injetáveis', uma vez que o jasper tem umas 12 milhôes de classes e talz...

E se lá no beans.xml, nós adicionassemos um exclude para todo o jasper ?

...só compartilhando...me veio essa idéia na cabeça..uma vez que já fiz uma dessa quando fiz uma interface web para uma app java antiga.

[tiago.javaman]

Carlos, não faço menor ideia de como melhorar isso, qualquer idéia é bem vinda.

O vraptor em si é leve, mas é quase indispensável o jasper nos projetos, visto que é o mais usado pra gerar os relatórios.

Me explica melhor essa parte, "E se lá no beans.xml, nós adicionassemos um exclude para todo o jasper ? "

O que acontece na prática com isso ?

[Rafael Ponte]

Oi,

O CDI pode scanear todas as classes do projeto e torná-las passíveis de injeção. Isso gera metadados no contêiner do CDI que devem ocupar um espaço considerável de memória já que todas as classes do Jasper e suas dependências estão sendo mapeadas no contêiner.

Você pode desligar isso no beans.xml marcando que o discovery é via anotação e não "ALL".

Um abraço,

Rafael Ponte

TriadWorks | Formação Java
http://cursos.triadworks.com.br

[tiago.javaman]

Oi Rafael, obrigado por responder.

Então, somente altero o beans.xml  assim bean-discovery-mode="annotated" ?

Posto em breve os resultados de memória.

[Carlos Spohr]

Tiago e Rafael,

Não lembrava de cabeça da parametrização lá do beans.xml, mas com base no que o Tiago disse de quando adiciona a dep do jasper e o consumo de memória padrão fica alta, as vezes pode ser devido ao scan de algum modo.

Vamos ver como ficam os resultados dos testes do Tiago pra ter uma idéia melhor, mas concordo com o Rafael quanto que ao vraptor ser muito enxuto.

[tiago.javaman]

Carlos e Rafael, segue as imagens para comparação.

O primeiro teste se refere ao mode "all" e o segundo com "annotated".

Notei uma pequena diferença sim, mas pra pior no meu ver:

No modo "all" ele teve um salto a 325mb mas se manteve no geral entre 130 a 290.

No modo "annotated" ele teve um salto a 315mb mas se manteve no geral entre 150 a 290.

O número de threads não houve alteração, e quanto as classes loaded sim, 7300 x 7299.  

[Carlos Spohr]

Vish,

Qual versão do jasper você adicionou aí ?

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vrapto...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para caelum-...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/caelum-vraptor.
Para mais opções, acesse https://groups.google.com/d/optout.

[tiago.javaman]

Como mencionei no inicio Carlos, estou testando com o plugin mesmo "vraptor-jasperreport", ele usa a versão 5 ainda.

[Carlos Spohr]

Uhmm...eu lembro que até a versão 5.6.1 não mudava nada quando a bugs existentes, acredito que pra questão de performance não vá dar diferença no final.

Poderia fazer um teste com a versão 6.2.2 pra ver...porém aí já seria necessário usar a IDE nova que é baseada no Eclipse ao invés do Netbeans senão me engano.

[tiago.javaman]

Sim, fiz aqui Carlos, adicionei um exclude no plugin vraptor-jasperreport e adicionei a versão 6.2.2 do jasper.

Acredite, é pior ;/  salto passou facilmente dos 330mb agora.

[Carlos Spohr]

Aí complica...

Aqui é um serviço legado que tem o jasper 5.0.1, as vezes também fica dando uns pico de memória do nada..mas geralmente no log aparece que foi de algum recurso das libs do jasper..mesmo não tendo sido executado nenhum report.

[tiago.javaman]

Pois é Carlos, complicado, achei que poderia melhorar algo na minha aplicação mas nada adianta se o maior consumo vem de baixo.

Memória é dinheiro.  ;/

[Carlos Spohr]

uhum,

Nessa app aí que eu passei o print, enxuguei o máximo dela, mas volta e meia tenho uns leaks que só deus sabe de onde vem.

[Cleber Angelo]

Particularmente, tentei utilizar o Jasper e desisti. Tenho utilizado a geração de relatórios em html mesmo, convertendo-os para pdf através do XmlWorker do iText. Tentei fazer um filtro para capturar a saída html do servlet, depois de processar o jsp, mas não deu certo pra mim. 

O jeito foi gerar o html na mão mesmo e processá-lo com o XmlWorker para obter o pdf.

Att,

Cleber.

[Rafael Ponte]

Olá,

Sinceramente não tive problemas de memória com Jasper, estou até surpreso (exceto claro quando preciso gerar relatórios muito grandes).

Recomendo fazer um teste com Jasper sem uso do plugin ou mesmo sem uso do Vraptor para ter certeza que o problema é com ele.

Um abraço,