Galera,
Estou com um problema na minha aplicação. O consumo de memoria esta crescendo muito rapido.
Queria usar o profile do netbeans, mas nao posso instalar o netbeans pq o servidor nao tem a parte grafica.
Queria ver com voces de há um aplicativo que faça o monitoramento do consumo de memoria do meu aplicativo java.
Ja utilizei o JConsole mas ele nao me deu uma resposta precisa do que eu presciso.
Att
Vinicius Castro
Amigo,
Certa vez precisei monitorar a memória de meu app e fiz uma classe para obter as informações e tomar algumas decisões no app.
Usei o Runtime para pegar as informações…
Runtime runtime = Runtime.getRuntime();
NumberFormat format = NumberFormat.getInstance();
StringBuilder sb = new StringBuilder();
long maxMemory = runtime.maxMemory();
long allocatedMemory = runtime.totalMemory();
long freeMemory = runtime.freeMemory();
sb.append("free memory: " + format.format(freeMemory / 1024) + "\n");
sb.append("allocated memory: " + format.format(allocatedMemory / 1024) + "\n");
sb.append("max memory: " + format.format(maxMemory / 1024) + "\n");
sb.append("total free memory: " + format.format((freeMemory + (maxMemory - allocatedMemory)) / 1024) + "\n");Agora se o objetivo é monitor os gargalos… já tentou o visualvm?
Você também pode tentar display remoto… já tentou ???
Ok… vamos falar das ferramentas de verdade.
Se você usa o Netbeans, ele já vem com um profiler:
http://netbeans.org/features/java/profiler_pt_BR.html
Se você não usa o Netbeans, na pasta bin do JDK, há o VisualVM:
http://visualvm.java.net/
Em ambos os casos, é uma boa ligar a opção da VM:
-XX:-HeapDumpOnOutOfMemoryError
Que vai fazer com que a VM gere um status da memória imediatamente antes de matar a thread que causar o OutOfMemoryError.
Tanto com o profiler do netbeans, quanto com o VisualVM, é possível abrir esse arquivo e verificar como está a memória.
Também é uma boa verificar se o erro se trata de um OutOfMemoryError no PermGen space. Nesse caso, leia:
http://www.guj.com.br/java/92491-the-dreaded-permgen-problem
Detalhe: Esses profilers são mais leves e fáceis de usar do que o JHat, que os artigos que desse link que indiquei cita. Mas ainda vale a pena ler os artigos para entender bem o problema.
[quote=ViniGodoy]Ok… vamos falar das ferramentas de verdade.
Se você usa o Netbeans, ele já vem com um profiler:
http://netbeans.org/features/java/profiler_pt_BR.html
Se você não usa o Netbeans, na pasta bin do JDK, há o VisualVM:
http://visualvm.java.net/
Em ambos os casos, é uma boa ligar a opção da VM:
-XX:-HeapDumpOnOutOfMemoryError
Que vai fazer com que a VM gere um status da memória imediatamente antes de matar a thread que causar o OutOfMemoryError.
Tanto com o profiler do netbeans, quanto com o VisualVM, é possível abrir esse arquivo e verificar como está a memória.
Também é uma boa verificar se o erro se trata de um OutOfMemoryError no PermGen space. Nesse caso, leia:
http://www.guj.com.br/java/92491-the-dreaded-permgen-problem
Detalhe: Esses profilers são mais leves e fáceis de usar do que o JHat, que os artigos que desse link que indiquei cita. Mas ainda vale a pena ler os artigos para entender bem o problema.[/quote]
Vini… em relação a “ferramentas de verdade”, mostrei o que usei para ver o consumo de memória pois o sistema precisava manter o estado de muita coisa e podia estourar a memória e para isso não acontecer, tratava na aplicação, solicitando o usuário encerrar algumas tarefas para realizar outras… ( No caso o encerrar não era bem encerrar, mas sim serializar as classes, liberando da memória, mas quando ele retomava demorava um pouco mais para carregar )
Depois citei também o visual vm… e inclusive de tentar usar display remoto mesmo sem modo grafico (talvez não tenha as dependências necessárias para tal)…
Sim, não estava criticando o que você falou. É que o autor pediu por ferramentas prontas.
Eu já usei esse tipo de método também, e eles quebram um galho.
Fiz inclusive uma status bar para aplicações gráficas que fica exibindo o consumo de memória com eles. 
O legal de ter algo assim é poder identificar nos logs se o dump foi gerado por um comportamento do usuário. Muitas vezes analisar o heap dump é difícil, pois ele só mostra a situação após o problema já ter ocorrido.
Agora, se ele não pode usar ambiente gráfico, a dica era mesmo usar o -XX:-HeapDumpOnOutOfMemoryError e analisar o dump em qual ferramenta ele quiser.
Essa é uma daquelas flags sinistras que é sempre bom ter na manga.
Sim, não estava criticando o que você falou. É que o autor pediu por ferramentas prontas.
Eu já usei esse tipo de método também, e eles quebram um galho.
Fiz inclusive uma status bar para aplicações gráficas que fica exibindo o consumo de memória com eles.
O legal de ter algo assim é poder identificar nos logs se o dump foi gerado por um comportamento do usuário. Muitas vezes analisar o heap dump é difícil, pois ele só mostra a situação após o problema já ter ocorrido.
Agora, se ele não pode usar ambiente gráfico, a dica era mesmo usar o -XX:-HeapDumpOnOutOfMemoryError e analisar o dump em qual ferramenta ele quiser.
Essa é uma daquelas flags sinistras que é sempre bom ter na manga. [/quote]
Blz… sem problemas!!!
não conhecia essa flag… muito bom…
Mesmo assim… acho que vale a pena tentar o display remoto… não sei as dependências gráficas do visual vm mas acredito que sejam poucas.
Tem de ver tbem se é linux/solaris/etc
Ver a questão de firewall tbem…
Blza galera.
Vou estudar aqui essas opções que me foram dada e vou posto os resultados aqui.
Valeu moçada
Att
[quote=ViniGodoy]Ok… vamos falar das ferramentas de verdade.
Se você usa o Netbeans, ele já vem com um profiler:
http://netbeans.org/features/java/profiler_pt_BR.html
Se você não usa o Netbeans, na pasta bin do JDK, há o VisualVM:
http://visualvm.java.net/
Em ambos os casos, é uma boa ligar a opção da VM:
-XX:-HeapDumpOnOutOfMemoryError
Que vai fazer com que a VM gere um status da memória imediatamente antes de matar a thread que causar o OutOfMemoryError.
Tanto com o profiler do netbeans, quanto com o VisualVM, é possível abrir esse arquivo e verificar como está a memória.
Também é uma boa verificar se o erro se trata de um OutOfMemoryError no PermGen space. Nesse caso, leia:
http://www.guj.com.br/java/92491-the-dreaded-permgen-problem
Detalhe: Esses profilers são mais leves e fáceis de usar do que o JHat, que os artigos que desse link que indiquei cita. Mas ainda vale a pena ler os artigos para entender bem o problema.[/quote]
Ola amigo, veja se vc me dá uma direção para eu resolver um problema.
Então, tenho uma aplicação web que volta e meia ela trava e so reiniciando o tomcat6 para ela voltar ao normal.
Tirei o heapdump da aplicação e tirei os seguinte relatórios atraves do JHat
235568 instances of class org.eclipse.persistence.indirection.IndirectList
210596 instances of class org.eclipse.persistence.internal.indirection.BackupValueHolder
210594 instances of class org.eclipse.persistence.internal.indirection.UnitOfWorkQueryValueHolder
210476 instances of class org.eclipse.persistence.internal.indirection.QueryBasedValueHolder
131582 instances of class org.eclipse.persistence.internal.identitymaps.UnitOfWorkCacheKey
Sabe se tenho um problema ou isso é normal? Uso JSF1.2 e Eclipselink (postgres a base de dados)
Obrigado!