| Autor |
Mensagem |
|
|
Referências:
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
http://www.oracle.com/technetwork/java/hotspotfaq-138619.html
|
 |
|
|
Caros,
Gostaria de compartilhar minhas dúvidas e quem saber obter opiniões sobre o meu dilema com quem já passou por isso.
Herdei uma aplicação web com as seguintes características:
- Java 6 / Spring IoC e Web Flow / Hibernate / Banco Oracle RAC / Jetty 6.1.14
É uma aplicação crítica (24x7), que tem muita demanda de utilização, tanto na quantidade de acessos, quanto no peso dos processos que executa.
Hoje esta aplicação está rodando em 4 servidores físicos (2 CPUs quad core com 32 Gb RAM). Cada servidor tem 6 (seis) instâncias de Jetty rodando a aplicação.
Em média temos cerca de 50 conexões (requests) simultâneas em cada servidor. Ou seja, um volume considerável a atender. Logo, criação de destruição de objetos bem intenso.
As instâncias do mesmo servidor compartilham sessão, basicamente, pelo memcached. Então só preciso de balanceamento "stick session" para manter o usuário no mesmo servidor, podendo variar a instância do Jetty que o atende.
Acontece que, como herdei isso, muitas das parametrizações de tuning estão lá há tempos e sem uma documentação explicando as razões.
Vi que isso foi feito quando o havia só 2 servidores e cada um tinha apenas 8Gb RAM. Hoje o cenário é outro a não foi refeito o tuning.
As configurações passadas para a JVM são:
Ou seja, cada JVM aloca 1 giga RAM para a sua heap.
Não fiz testes de carga/stress ainda, mesmo porque os servidores estão em produção, mas acho que posso otimizar isso.
Talvez aumentando a memória da HEAP e diminuindo o número de instâncias de Jettys em cada servidor (de 6 para 4 ou 3).
Aumentando a memória para 2Gb pode chegar a ser um problema para o garbage Collector? Talvez ele tomar mais tempo e recursos do servidor para varrer e limpar objetos sem uso?
Alguma consideração?
|
|
|
|
|
A solução está no próprio tópico.
|
|
|
|
|
Bom, isso não é bem um pattern, mas sim uma implementação. Que eu colocaria tranquilamente aqui. rsrsrsrs (só brincadeira ok).
|
|
|
|
|
Quem nunca fez um código tosco que aperte a primeira tecla.
|
|
|
|
|
Acho que não vou precisar remover tópico mal educado ou de provocações, vou?
|
|
|
|
adriano_si wrote:Acho que poderíamos excluir essa última pérola, sendo que é de um de nossos amigos ativos aqui no fórum, que embora seja iniciante, ajuda bastante alguns outros iniciantes... Logo ainda não tem a experiência e o conhecimento da API apurados... Poderíamos dispensar ou manter o tópico sem conhecimento dos autores...
Enfim... é minha opnião...
Abs []
Link removido para manter anonimato do usuario.
|
|
|
|
http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/
10- Não existe refactoring, apenas rework.
Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma  .
|
|
|
|
God_of_Java wrote:Esse e um exmplo simples, no projeto em que participo criei uma superClasse, ficou bacana.
Isso é sério? hahahahaha
|
|
|
|
kkkkk... fala garoto, ainda na mesma empresa?
Sou da Gang of Myself.
|
|
|
|
|
São anos de experiência, meu caro... rsrsrs
|
|
|
|
|
Os códigos ruins que achei estão aqui: http://www.guj.com.br/java/30384-evgd-codigos-toscos
|
|
|
|
|
A onda já comeuçou.
|
|
|
|
|
Ele se parece com todos os outros patterns.
|
|
|
|
|
Será a nova tendência do mercado. Já vejo novos frameworks, middlewares e uma onda de produtos e serviços.
|
|
|
|