[luan.cestari]

O erro mudou? Se sim vc poderia colocar aqui novamente? O que sai se você der um cat no /etc/security/limits.conf? Coloca em um Gists para nos vermos. Coloca também a saído do 'jps -Vvml'

[rodrigo.parede]

Olá Luan,

Não apresenta mais erros no log.

Inserir a configuração:

user soft nofile 4096

user hard nofile 10240

Estou monitorando a VM pelo jconsole, aparentemente agora melhorou, eu alterei os parametretos para:

-XX:MaxPermSize=512m -XX:+UseParNewGC -XX:MaxNewSize=1g -XX:NewSize=1g -Xms6g -Xmx6g -XX:SurvivorRatio=128 -XX:MaxTenuringThreshold=0 -XX:+UseTLAB -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Porém ainda possui algum gargalo, ao longo do tempo o heap vai ficando atolado. Vou postar o grafico do Overview agora e depois posto quando estoura

Ontem quando caiu o gráfico do heap estava mínimo 5..G e 6G, as Threads estava em 500 e a CPU no talo 90%, mas a audiência não era diferente da atual.

[marcelomrwin]

Oi Rodrigo. Não estou acompanhando tanto teu caso, também não sei se você já respondeu, mas algumas coisas me deixaram com duvida com relação ao teu ambiente.

Quantas aplicações você tem implantadas neste teu jboss?

Você está usando standalone ou domain?

Quantos usuários em média você supõe estarem usando a aplicação (ou as aplicações)?

Você já pensou em habilitar o StuckThreadValve para avaliar nas aplicações quais podem estar demorando pra liberar thread e consequentemente responder ao usuário?

Poderia sugerir também incluir um filtro http nas aplicações (ou aplicação) para capturar informações que te auxiliem a identificar requisições que chegam e podem não sair.

Verifica também se tuas aplicações não estão usando pool de conexões JDBC internas e se o MaxStatement não está com valor muito alto. Muitas vezes as consultas SQL ficam acumuladas por um statement cache muito grande.

Bem, são algumas dicas que poderia te passar pra tentar te ajudar a identificar o problema.

Grande abraço

Marcelo Daniel Sales

[luan.cestari]

Faz bastante sentido. Realmente seria bom ver se nao eh um bug na aplicacao que nao libera as threads (e/ou esta consumindo muita CPU nao dando tempo para demais threads do sistema (OS) trabalharem)

[luan.cestari]

Voce poderia por exemplo colocar no cron para salvar um thread dump a cada X segundos/minutos/horas, onde o tempo e sua respectiva unidade tem que ser ajustada de acordo com o intervalo que o problema ocorre (se o problema dura meia hora de lentidao, colocar cron de uma e uma hora pode nao pegar os dados do problema, logo seria util um cron de meia e meia hora ou menos)

[rodrigo.parede]

Olá Marcelo, Seguindo seu conselho, achei um problema relacionado a abertura de conexões.

O MaxStatement estava configurado com o valor de 200, fiz o ajuste para 100, mas ainda esta abrindo muitas conexões, estou verificando com os DBAs, se acha algum problema nos logs.

Será que o problema pode estar relacionado ao drive de conexão no ambiente antigo utilizava jtds-1.2.1.jar e novo atualizamos para jtds-1.2.8.jar

Sobre a aplicação: pode conter algum problema, mas estamos mudando principalmente os servidores estrutura.

Você já pensou em habilitar o StuckThreadValve para avaliar nas aplicações quais podem estar demorando pra liberar thread e consequentemente responder ao usuário?

Procurei sobre StuckThreadValve, mas não achei nada, pode me dar uma luz sobre como usar ou melhor algum artigo.

Obrigado até o momento galera.

[adrianoschmidt]

Tenho duas sugestões...

1) Avaliar as aplicações atuais... são muitas? Tire algumas delas para identificar se é alguma aplicação específica que está causando os problemas.. ou use ferramentas como o NewRelic, VisualVM, jConsole para analisar mais a fundo o que está acontecendo

2) Qual JVM você está utilizando? Não sei a opinião do pessoal aqui, mas recomendo você usar a JRockit.. vi você falando sobre alguns problemas de memória, com o MaxPermSize por exemplo, com a JRockit esse gerenciamento é, na minha opinião com base em diversos testes que já realizer, melhor.

Abraço!

Adriano Schmidt

http://www.localhost8080.com.br/

[rimolive]

Complementando a resporta do Adriano: Com a jRockit você nem terá problemas com PermGen pois ela não possui em sua estrutura de memória.

Vendo seu gráfico, percebi que em diversos momentos o Heap bate quase que o topo, se aproximando cada vez mais do valor máximo da Heap. Considere avaliar a aplicação para assegurar que não há memory leak, pois isso pode te trazer problemas mesmo com a configuração perfeita da JVM.

[rodrigo.parede]

Bom dia galera.

Vim postar os passos que fiz para chegar a conclusão, ainda não esta 100% mas cheguei em um a normalidade....

Bom primeiro passo vou olhar a aplicação com mais calma para identificar os vazamentos de conexão, foi um pouco complicado pois tinha um jar que fazia a autenticação dentro das aplicações e não fechava as conexões de forma correta. Erro concluído. (no jboss 4 fechava as conexões, por isso foi complicado localizar)

Mas o problema de queda ainda permaneceu, então mudamos o modulo do apache para mod_cluster (realmente trabalha muito melhor), mas só melhorou de verdade quando mudei do modo standalone para domain, além de dividir em pequenas instancias e não uma gigantesca imagino que o domain vem com algumas pré-configurações que ajudaram no funcionamento do sistema.

Obrigado a todos.

[luan.cestari]

Você tem algum log do erro quando quando ocorre a queda? Você viu também a Heap e o GC como estavam?

[rodrigo.parede]

Oi Luan,

Creio que realmente solucionou problema migrando para o mod_cluster, depois dessa mudança não tive mais picos de aumento de threads, imagino que não estava configurado direito ou faltava algum ajuste no mod_proxy, já o mod_cluster conversa "magicamente" com o apache.

[luan.cestari]

Que bom, fico feliz em saber que o problema foi resolvido =)