Aplicação CRUD pode deixar vestigios na memoria?

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… :wink:

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.