Pessoal, criei uma aplicação CRUD que acessa um banco de dados mysql de 1 em 1 segundo, faz uma verificação e dependendo da resposta desta envia informações do banco a uma aplicação delphi via socket. Acontece que depois de um tempo, tipo umas horas usando o CRUD, os usuários reclamam que a aplicação Java fica lenta e após reiniciar o computador volta a ficar normal. Pergunto, será que a aplicação java está deixando algo na memoria?
A melhor forma de saber isso é usar um profiler como o VisualVM que vem a partir da jdk 1.6_15 se não me engano.
Junto com uma ferramenta de load test, como o JMeter pra analisar os picos e releases de memória.
Fora isso fica difícil saber se há possíveis leaks de memória sem ver o código, o que vc precisa fazer é uma investigação com as ferramentas sugeridas.
Pode deixar vestígios sim, principalmente se os objetos não gerenciáveis não foram devidamente tratados, como conexões.
Vai na máquina que está instalado o programa e abre um prompt de comando:
Seu diretório de Instalação do Java >> /bin >> jvisualvm.exe
Pronto, vê o consumo de memória
[quote=Tchello] A melhor forma de saber isso é usar um profiler como o VisualVM que vem a partir da jdk 1.6_15 se não me engano.
Junto com uma ferramenta de load test, como o JMeter pra analisar os picos e releases de memória.[/quote]
Como faço isso?
Qual parte do código precisa ver?
[quote=Pedro Ribeiro][quote=Tchello] A melhor forma de saber isso é usar um profiler como o VisualVM que vem a partir da jdk 1.6_15 se não me engano.
Junto com uma ferramenta de load test, como o JMeter pra analisar os picos e releases de memória.[/quote]
Como faço isso?[/quote]
No windows:
Iniciar >> Executar >> cmd
java -version --> Veja a saída. Se a versão do seu jdk for maior que 1.6_15, então você pode rodar o jvisualvm
Isso não tem nada a ver. Qualquer algoritmo mal feito pode arrebentar com o desempenho de um programa. Não importa se o código é nativo, bytecode e/ou gerenciado por coletor de lixo(que pode existir em programas nativos também).
O que precisa ser feito é uma análise em cima do comportamento do programa e melhorar o código nessas áreas críticas. A jvisualvm é uma ótima ferramenta para isso.
Isso não tem nada a ver. Qualquer algoritmo mal feito pode arrebentar com o desempenho de um programa. Não importa se o código é nativo, bytecode e/ou gerenciado por coletor de lixo(que pode existir em programas nativos também).
O que precisa ser feito é uma análise em cima do comportamento do programa e melhorar o código nessas áreas críticas. A jvisualvm é uma ótima ferramenta para isso.[/quote]
Experimenta deixar as conexões de banco de dados abertas na mão do GC… 
Isso não tem nada a ver. Qualquer algoritmo mal feito pode arrebentar com o desempenho de um programa. Não importa se o código é nativo, bytecode e/ou gerenciado por coletor de lixo(que pode existir em programas nativos também).
O que precisa ser feito é uma análise em cima do comportamento do programa e melhorar o código nessas áreas críticas. A jvisualvm é uma ótima ferramenta para isso.[/quote]
Experimenta deixar as conexões de banco de dados abertas na mão do GC… ;)[/quote]
Pois isso não é um algoritmo mal feito?
O que você disse e não tem nada haver é o fato de:
Não interessa se é gerenciado ou não. Se sua lógica é ruim o resultado é porco.
Tá bom amigo, usando lógica. mais precisamente regressão lógica, vemos que as duas afirmativas, minha e sua estão verdadeiras, agora não pose de sabichão querendo corrigir o certo.
É por isso que minha participação no fórum tem diminuído, o pessoal fica discutindo por pescoço de frango.
Pedro Ribeiro, faça o seguinte:
Anexe o profiler (visualVM por exemplo) na sua aplicação.
Comece a utilizar recurso por recurso e vá reparando nos gráficos do profiler onde há o maior consumo de memória e possíveis leaks.
Anote os pontos do sistema que te levantar suspeitas e analise o código cuidadosamente, poste aqui se tiver dúvidas.
Se quiser algo maior, crie scripts de testes de estresse com JMeter e analise os resultados, se preferir pode deixar a visualVM junto pra ter algo ainda mais preciso. Repita o procedimento dos pontos de suspeita.
Abraços.
[quote=Tchello] É por isso que minha participação no fórum tem diminuído, o pessoal fica discutindo por pescoço de frango.
Pedro Ribeiro, faça o seguinte:
Anexe o profiler (visualVM por exemplo) na sua aplicação.
Comece a utilizar recurso por recurso e vá reparando nos gráficos do profiler onde há o maior consumo de memória e possíveis leaks.
Anote os pontos do sistema que te levantar suspeitas e analise o código cuidadosamente, poste aqui se tiver dúvidas.
Se quiser algo maior, crie scripts de testes de estresse com JMeter e analise os resultados, se preferir pode deixar a visualVM junto pra ter algo ainda mais preciso. Repita o procedimento dos pontos de suspeita.
Abraços.[/quote]
Perfeito!
Não leva a mal não, mas isso que você disse não está certo. Foi isso que eu quis mostrar. O fato de ser gerenciável ou não, não faz a menor importância.
uma lista em um evento qualquer sem visibilidade pode virar um leak, e listas são gerenciáveis.
Não vou discutir mais. Haja saco.
Mas se fosse código o aplicativo não ficaria lento o tempo todo e não depois de um tempo de uso?
não necessáriamente… dependendo do caso a aplicação vai acumulando recurso não fechado na memória, gradativamente conforme abre e não fecha vai aumentando o uso, como não descarta o que ja usou e mantém, vai acumulando, conforme vai usando vai acumulando, com o tempo tem bastante mas com pouco uso (o que costuma estar relacionado com o tempo) não…
Exato! E muitas vezes esses problemas são “solucionados” aumentando a memória heap em vez de corrigir os algoritmos.
Outra ferramenta legal pra você corrigir os algoritmos é o FindBugs.
Exato! E muitas vezes esses problemas são “solucionados” aumentando a memória heap em vez de corrigir os algoritmos.
Outra ferramenta legal pra você corrigir os algoritmos é o FindBugs.[/quote]
Não adianta aumentar a memória da jvm. O leak vai consumir toda a memória não importa a quantidade, é só uma questão de tempo.
Exato! E muitas vezes esses problemas são “solucionados” aumentando a memória heap em vez de corrigir os algoritmos.
Outra ferramenta legal pra você corrigir os algoritmos é o FindBugs.[/quote]
Não adianta aumentar a memória da jvm. O leak vai consumir toda a memória não importa a quantidade, é só uma questão de tempo.[/quote]
Pois é. Já vi heaps de 8 gigas por causa disso. Outra “solução” maluca foi um schedule pra reiniciar o servidor toda meia-noite.
Enfim, é muito melhor corrigir o código.