Seus relatorios abrem conexao com o banco de dados (datasource), ou vc só
manda objetos pojos pra ele?

Ressalto a dica do Rafael sobre o JProfiler, ele é muito bom para achar
esses leaks.
Threading issues pode ser varias coisas, a mais conhecida são inumeras
requisicoes abrindo conexoes de dados separadamente.

Tb veja a possibilidade de usar um pool de conexoes no seu servidor, dá uma
pesquisada é fácil de configurar.

Dá um retorno pra gente, []'s






Em 3 de fevereiro de 2011 19:24, RafaelViana <[email protected]> escreveu:

> Outra dica para achar onde sua aplicação está consumindo mais.
>
> -Use um profiler na aplicação Java. Eu gosto do YourKit Java Profiler,
> mas também tem o JProfiler. Ambos são pagos, mas tem versões trials
> para você testar.
> Com um profiler você saberá onde sua aplicação está gastando cada MB
> de memória. Sabendo aonde atacar na otimização.
>
> On Feb 3, 6:59 pm, RafaelViana <[email protected]> wrote:
> > Vamos ser se consigo colaborar. Já passei por um leak uma vez...
> > No meu caso como uso Hibernate eram 3~4 pontos do sistema onde o
> > connection não era fechado.
> >
> > Está usando pool de conexões? Dificilmente é a causa de um leak, mas
> > conexões são objetos caros para criar. Pode ser considerada como opção
> > para otimização.
> > Utilize seu gerenciador do banco MySql para verificar como estão os
> > processos do banco. Existe algum locked? existe algum aberto há muito
> > tempo? (melhor maneira de verificar se ficou alguma conexão aberta no
> > sistema..)
> >
> > Você disse que não esta ocorrendo quedas? Só ocorreu ao gerar um
> > relatório? Quantas páginas tinha o relatório?
> > Provavelmente, está usando JasperReports. Dê uma olhada na
> > possibilidade da virtualização dos relatórios. (para fazer o
> > carregando por partes) carrega um parte e joga para uma pasta
> > temporária, e faz isso até terminar o processo... assim não fica tudo
> > na memória.
> > De nada adianta deixar a aplicação toda otimizada e tentar gerar um
> > relatório de 15.000 páginas.
> >
> > Outra dica muito importante, 99,9% das aplicações não precisam de
> > perfomance 100% não tente procurar otimização onde não existe. Porque
> > o ganho será imperceptivel em muitos casos.
> >
> > Você disse que está usando o Lamba Probe. Vai em System Information.
> > Ali tem Current memmory usage is:
> > Em baixo tem: Free, Total, Max. Me diga esses três valores quando a
> > aplicação sobe. E esses três valores quando a aplicação está travando.
> >
> > On Feb 3, 5:34 pm, icaroqr <[email protected]> wrote:
> >
> > > Adicionado a resposta acima, os objetos Connection também são fechados
> > > no finally de cada try/catch que executa uma operação no banco. Ficou
> > > faltando essa informação impotante! hehe
>
> --
> Você recebeu esta mensagem porque está inscrito na lista "flexdev"
> Para enviar uma mensagem, envie um e-mail para [email protected]
> Para sair da lista, envie um email em branco para
> [email protected]
> Mais opções estão disponíveis em http://groups.google.com/group/flexdev
>



-- 
Mario Junior
http://blog.mariojunior.com/
@mariojunior

-- 
Você recebeu esta mensagem porque está inscrito na lista "flexdev"
Para enviar uma mensagem, envie um e-mail para [email protected]
Para sair da lista, envie um email em branco para 
[email protected]
Mais opções estão disponíveis em http://groups.google.com/group/flexdev

Responder a