Servidor travando diariamente

Bom dia !

Você chegou a verificar nos logs da sua aplicação rodando no servidor se apareceu alguma mensagem do tipo java.lang.OutOfMemoryError ?
Questione ao provedor, qual é a versão do java que sua aplicação está usando ? Peça ao mesmo como está sendo feita a configuração da JVM pra que comece a investigar onde está de fato o problema…

Outra coisa, sua aplicação, antes de levar ao servidor sofreu um stress test pra saber como ela se comportaria ? Se não, dá uma pesquisada sobre stress test para aplicações web.

Assim que tiver essas informações, posta aí os resultados.

Atenciosamente

Anderson

Já ocorreu esse error OutOfMemory sim, só que acabei por solucioná-lo limitando o ResultSet das pesquisas de banco, com isso ele sumiu.

Nos logs do tomcat só encontrei mesmo aquele erro que mencionei.

Agora não cheguei a fazer esse stress test. Saberia me indicar algum?

Com uma rapida pesquisada vi que se tratava de um aplicativo que efetua esse stress test.

Será que o uso de struts 2, ajax e hibernate influenciam em qual ferramenta utilizar?

variável int com o valor null, e ele retornada essa exception. Só que esse error se repete várias, váaááárias vezes.

essa variável poderia estar em loop infinito?

Aplicação do que? e qtos usuários simultaneos?

Esse erro acontece toda vez que se envia um formulário de pesquisa ou cadastramento, não tenho ainda certeza qual.

Portanto não seria um loop, é só que essas pesquisas e cadastros são feitos com frequência.

São em média 60 usuario simultâneos…não acredito que isso fosse pesar tanto assim.

renangd:

Esse erro acontece toda vez que se envia um formulário de pesquisa ou cadastramento, não tenho ainda certeza qual.

Portanto não seria um loop, é só que essas pesquisas e cadastros são feitos com frequência.

São em média 60 usuario simultâneos…não acredito que isso fosse pesar tanto assim.

60 Usuários em um container Tomcat
fazendo pesquisas complicado hein

vê se é possivel vc utilizar a ferramenta Visual VM

Bom…

60 usuários simultâneos, fazendo transações consultas no banco, etc e tal… Eu não vejo que isso possa complicar o processamento do servidor, desde que ele contenha um hardware adequado para suportar este processamento bem como se a utilização de memória na JVM estiver configurada da maneira correta. Tudo depende de como a aplicação foi projetada…

Fazer invocação do GC explicitamente também não resolve, uma vez que mesmo invocando explicitamente na aplicação, não é garantia de que a thread do GC será chamada no mesmo instante…

Já vi aplicações trabalharem com milhares de registros a serem exibidos - aplicações de grande porte - e tiveram JVM privativa de 100 MB e trabalharam bem…

Sobre a questão de Stress Test, procure saber sobre o JMeter… Na minha opinião, é uma das melhores ferramentas de stress test que pude conhecer…

Com relação ao banco de dados, a aplicação usa pool através de data source ? ou JDBC nativo ?

Esgotando todas os recursos, poderemos chegar a um consenso sobre essa questão.

Valeu !

Anderson

Cara, uso o JDBC nativo mesmo.

Que eu me lembre, a unica configuração de pool que eu fiz foi no hibernate.cfg, definindo o pool size para 0.

Vou dar uma olhada nesse JMeter.

Minha aplicação usa AJAX à quase todo instante, mas nao acredito que o ajax seria o problema.

E realmente não é…

Só que a utilização de recursos JDBC de forma não otimizada, pode detonar com o processamento tanto no servidor web quanto no banco de dados… Você sabe informar se o banci de dados e a application ficam no mesmo host ou são separados ?

Como sugestão, procure mudar a sua forma de conexão para pool de conexões com DataSource, usando como configuração base, o que é passado na documentação do tomcat… além de checar se as conexões com o banco estão sendo fechadas adequadamente após a realização de suas transações. Outra coisa, procure limitar o número de conexões ativas no servidor e acompanhe o desempenho de sua aplicação.

Procurando executar essas otimizações, acredito que pode haver uma melhora na sua application, antes de fazermos a “marretada” que é o reinicio diário do servidor… deixando ele pra último caso.

Valeu !

Anderson