Aplicação consome toda a memória, travando as demais.

[Anderson Matos]

Salve pessoal!

Ha algum tempo venho sofrendo com o seguinte problema:

Tenho várias aplicações rodando no Tomcat 7 e dentre elas tem uma que gradativamente vai consumindo toda Memória e Uso de CPU.

Quando isso acontece, todas as outras aplicações ficam inacessíveis, ou seja, trava tudo. Daí reinicio o Tomcat e tudo volta ao normal até que a bendita aplicação consuma tudo novamente. E assim to seguindo a vida. 

Outro dia no momento em que estava tudo travado, dei uma olhada nos processos e dei um jtask no PID que estava com o maior consumo e vi que era o GB (Garbage Collector) que está acabando com tudo. Daí criei o arquivo tomcat/bin/setenv.sh com o seguinte conteudo: export JAVA_OPTS="-Xms1024m -Xmx1024m -XX:MaxPermSize=512m" (não sei se falta algum parametro neste arquivo) mas mesmo assim não obtive sucesso.

Venho aqui apelar pela ajuda de vocês. Agradeço aos que se interessarem pelo caso.
Obrigado!

Ambiente:
- Ubunto Server12.04 x64

- 8 GB RAM

- Java 7

- Tomcat 7

Aplicação:

JSF 2

Primefaces

JPA

iReport

SQL Server

[Arthur Gregório]

Isso é um problema bem clássico, pode ser sua app como também uma lib... Tive um caso idêntico ao seu mas era o Infinispan executando algumas operações de cache que estouravam a minha heap.

Bastaria aumentá-la como vc fez, mas isso apenas iria aumentar o tempo que o problema levaria para ocorrer.

A melhor forma de saber o que esta rolando, é setar um valor aceitável para a sua perm space e a heap e em seguida rodar um profiler da aplicação para descobrir se não pode ser alguma falha de programação sua ou alguma lib zoada.

O Netbeans tem um profiler bem legal para coisas simples, mas vc também pode usar o Java Mission Control.

at.,

Arthur P. Gregório
+55 45 9958-0302
@gregorioarthur
http://arthurgregorio.eti.br/blog/

http://arthurgregorio.github.io/web-budget/

--
Você recebeu essa mensagem porque está inscrito no grupo "javasf: JavaServer Faces Group" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para javasf+un...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/javasf.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/9f728032-85bb-4701-a218-44103a3ed08a%40googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[Rafael Ponte]

Olá,

Aumentar a memoria do Tomcat é uma solução paliativa, daqui algumas semanas você terá que aumentar novamente até um ponto que sua máquina não possui mais memoria fisica.

Como o Arthur comentou, aumente a memoria nesse momento e rode um profiler para descobrir qual a aplicação está consumindo memoria e o local exato (classe ou componente ou lib). Não é uma tarefa simples, dependendo do vazamento de memoria isso pode ser descoberto em 1h como em 2 semanas.

Se você tem idéia de qual aplicação está dando problema então fica mais fácil, pois você pode isolá-la num Tomcat a parte (na sua máquina mesmo) e extressar ela. Talvez você ache o vazamento, talvez não. Tudo depende do tamanho do "buraco".

Um abraço,

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/CA%2BUvXkKAFz5Q8f5AuWRxNQo8Trboe%2BZUm%3DY%3DwKQfgkg1Prfebg%40mail.gmail.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Rafael Ponte

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

[Anderson Matos]

Olá Rafael!

Então, sei qual é a aplicação sim, e o problema está relacionado com o Garbage Collector. O problema é que não tenho a minima ideia de como resolver.

[Rafael Ponte]

Oi,

O problema nao é o GC, ele faz bem o trabalho dele, mas sim a aplicação que continua referenciando objetos que deveriam ser descartados :-)

Acredite em mim, 90% dos casos de vazamento de memoria a culpa é da aplicação!

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/ebac2aab-ee7c-483f-b456-2ea97db13ac0%40googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

[Fernando Schmitt Daufemback]

Olá, 

Passei por isso, e as vezes ainda acontece, no meu caso era algumas Threads que eu não finalizava de forma correta.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/CAJswn6xQzMVxAB0gjDjDq06ehs48dy2LPjasQXeraFxodDfnvA%40mail.gmail.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Fernando Schmitt Daufemback
Phone: + 55 (48) 3648-2061
Mobile: + 55 (48) 9145-4944 / 9608-6628

[Anderson Matos]

Sim sim, acredito. Entendi.

[Anderson Matos]

Pode citar exemplos (bem prático), Fernando?
Obrigado.

[Levy Moreira]

Baixa o trial desse cara aqui:

https://zeroturnaround.com/software/xrebel/

Sobe o app com ele ativado, se ainda assim não achar,

configura tua vm pra gravar um dump ao estourar a memoria (HeapDumpOnOutOfMemoryError) e abre o dump com esse rapaz: http://www.eclipse.org/mat/ 

que ele mostra quem ta comendo a memória. (Obg. Rafael Ucha pela dica)

--

Levy Moreira

[Arthur Gregório]

Profiler, ele vai te dizer certinho onde é.

Arthur P. Gregório
+55 45 9958-0302
@gregorioarthur
http://arthurgregorio.eti.br/blog/

http://arthurgregorio.github.io/web-budget/

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/d5201cf2-5cba-447e-a18e-3bc98072864e%40googlegroups.com.

[Fernando Schmitt Daufemback]

Uma aplicação que acessa alguns webservices cada conexão é uma thread,  quando a conexão cai ou cai Internet preciso refazer a conexão,  eu iniciava uma nova thread para isso,  a anterior continuava processando e ocupando memória. Ao longo do tempo dava permGen....

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/d5201cf2-5cba-447e-a18e-3bc98072864e%40googlegroups.com.

[Fernando Schmitt Daufemback]

Boa dica Arthur, também não usava.

[Arthur Gregório]

O Java Mission Control que vem no JDK já resolve, com ele da pra acompanhar tudo. 

No Netbeans o profiler integrado também já da uma ajuda, e ele é mais simples de operar.

at.,

Arthur P. Gregório
+55 45 9958-0302
@gregorioarthur
http://arthurgregorio.eti.br/blog/

http://arthurgregorio.github.io/web-budget/

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/CAG%3DD%3DOr13V-3BDVEr15A58MRwEDg2NPZ7-n0OL0hB1opV-Ns8w%40mail.gmail.com.

[Davi Mustafa]

Não aparece nenhum erro na aplicação? As vezes ate configurações de banco de dados causam isso.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/CA%2BUvXkKZSC_NymBNd%2ByhScYDvuiDhh_ysUi_f%2BTjaTkjf1VnfQ%40mail.gmail.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Davi Mustafa

[Everton Fujimoto]

Como disseram, pode ser muitos problemas diferentes causando isso e o GC funciona muito bem. 

Alguns problemas bem comuns são:

1. Collections em escopo "estático". 

2. Processo/thread em algum escopo de aplicação (Exemplo, EJB Singleton) que utiliza JPA sem dar um "clear" no entity manager (por exemplo, um while(true) que fica consultando na base)

3. Threads "soltas" na memória comendo processamento e memória. 

4. JMS lançando exception (famoso "hot potato"), mas nesse caso é mais difícil dar erro de heap. 

A sugestão mais prática que conheço é quando estiver com esse erro (ou depois de um certo tempo com a aplicação na memória) em produção tirar um dump com jhat, baixar para a sua máquina e subir ele numa porta com o jmap. (ou o contrário, não lembro) Embora as sugestões com os profilers também sejam boas, geralmente não é possível usá-los em produção. 

Att.

Everton William Fujimoto

Tecnólogo em Processamento de Dados - Fatec-SO

Especialista em Gestão de Projetos de Software - IGTI

Mestrando em Administração - UFSC

OCAJP, OCPJP, OCEWCD, OCEWSD, OCEJPA, OCEEJB, OCEJSF, 1Z0-807, OCE SQL Expert

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/CAJuoL2hA_7ACRA_jLv9tZYggw3tTTQ49iyyYy3JETTJKd-GZzg%40mail.gmail.com.

[Joaquim Hangalo]

Na verdade a minha alguma experiencia diz que o problema tem a ver com as consultas com JPA.

Se eventualmente voce faz as pesquisas directamente sobre as entidades... voce acaba carregando objectos inuteis que consomem toda a memoria...

Se for o caso o ideal e' criar classes auxiliares para fazer as consultas.... usando  SELECT NEW

veja dicas neste link

http://blog.michaelnascimento.com.br/2012/08/21/typedquery-e-select-new-dois-excelentes-recursos-pouco-utilizados/

--

Você recebeu essa mensagem porque está inscrito no grupo "javasf: JavaServer Faces Group" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para javasf+un...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/javasf.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/9f728032-85bb-4701-a218-44103a3ed08a%40googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--

"Só imprima esse e-mail se for realmente necessário, evite ao máximo o desperdício de papel. O papel reciclado utiliza aproximadamente 60% menos energia e água para ser feito do que o papel novo. Use papel reciclado."

[Anderson Matos]

Pessoal, bom dia!
Gostaria de agradecer a todos pelas as sugestões.

Vou experimentar as soluções propostas e volto aqui para futuras dúvidas.
Obrigado.

[Anderson Matos]

O Garbage Collector é um recurso fornecido pela plataforma Java que elimina a necessidade do desenvolvedor liberar explicitamente objetos da memória. Porém, o custo disso é o overhead de desempenho quando a coleta de lixo é executada. Ou seja, digamos que eu possua uma página de busca cujo seu controller é de @SessionScoped. Com isso quando feita a busca, é carregado uma lista e esta armazenada na sessão. Mesmo que eu saia da página de busca, ainda assim ficará na memória e com o decorrer do tempo, vir a causar o problema em questão. Correto? Pode ser isso uma das causas?

Em sexta-feira, 3 de junho de 2016 14:12:14 UTC-3, Anderson Matos escreveu:

[Davi Mustafa]

a pagina carrega tanta informação assim? você tem muitos controllers SessionScoped?

--

Você recebeu essa mensagem porque está inscrito no grupo "javasf: JavaServer Faces Group" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para javasf+un...@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/javasf.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/712022db-1ec9-4444-8adc-015c9e1290d2%40googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Davi Mustafa

[Anderson Matos]

Tenho

[Davi Mustafa]

Há a necessidade disso ou tu acha que poderia tentar usar o view scoped e ver se melhora?

Usando escopo de que? Spring? JSF? CDI?

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/b6e38b16-e1f5-4595-bae7-88a6cdd6c0aa%40googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Davi Mustafa

[Anderson Matos]

JSF. Não, não há a necessidade. Já estou analisando a mudança. Mas ainda assim, gostaria de saber:

O Garbage Collector é um recurso fornecido pela plataforma Java que elimina a necessidade do desenvolvedor liberar explicitamente objetos da memória. Porém, o custo disso é o overhead de desempenho quando a coleta de lixo é executada. Ou seja, digamos que eu possua uma página de busca cujo seu controller é de @SessionScoped. Com isso quando feita a busca, é carregado uma lista e esta armazenada na sessão. Mesmo que eu saia da página de busca, ainda assim ficará na memória e com o decorrer do tempo, vir a causar o problema em questão. Correto? Pode ser isso uma das causas?

[Arthur Gregório]

Recomendo a leitura: http://javapapers.com/java/how-java-garbage-collection-works/

Outra coisa é usar os escopos corretos, no JSF usar algo por usar vai lhe custar um caro dependendo da situação.

Arthur P. Gregório
+55 45 9958-0302
@gregorioarthur
http://arthurgregorio.eti.br/blog/

http://arthurgregorio.github.io/web-budget/

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/a3a06759-8080-4c35-ad72-10af8e902e43%40googlegroups.com.

[Anderson Matos]

Blz. Vlw Arthur!

[Ricardo Johannsen]

você utiliza muitos beans viewscope, se sim dá uma observada neles, muita gente reclama de problemas com memoria relacionado ao escopo view, o escopo view não funciona tão perfeito quando se imagina, se você utiliza então navegação com get em suas páginas as coisas pioram, você troca de página mas o maldito do bean fica lá em uma estrutura de dados chamados LRU .Pior por padrão pode armazenar até 25 beans viewscope, oque pode ser até mais nocivo que utilizar o bean no escopo de sessão, se estiver utilizando view scope investiga se eles estão sendo destuidos. Se o problema for esse eu aconselho a usar ViewAcessScoped do DeltaSpike

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/e3b196ad-94a5-4954-9ab4-2f76a5504a15%40googlegroups.com.

[Anderson Matos]

Não sabia dessa. Obrigado pelo alerta.

[Ricardo Johannsen]

O BalusC explica o problema melhor que eu: hehe http://stackoverflow.com/questions/15265433/how-and-when-is-a-viewscoped-bean-destroyed-in-jsf

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/df0632ed-0a7b-408f-8097-2b81886a6c32%40googlegroups.com.

[Rafael Ponte]

Opa,

Boa dica Ricardo. A verdade é que o momento em que os beans @ViewScoped são destruídos nem é o problema de fato, caso seja, pode-se diminuir o número de views "cacheadas" por usuário. Na minha opinião o principal problema tem a ver com o que se coloca num managed bean, por exemplo, uma lista com todos os registros do banco de dados, ou um relatório PDF de 5mb etc.

As configurações padrões do Mojarra funcionam bem para maioria das aplicações, principalmente se você mantém sua aplicação sempre com o JAR mais recente do JSF. E claro, estou falando JSF 2.x, pois JSF 1.2 era horrível com relação a consumo de memória.

Um abraço,

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/javasf/CAAOUEbMVgNazxyDsyV9EumziEW5_az%2B82niUe2wLS2EjguLi5w%40mail.gmail.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

[Anderson Matos]

Boa, Raphael!