Usando o VisualVM reparei uma coisa estranha
[code]
-client
-Xms24m
-Xmx256m
-Dsun.jvmstat.perdata.syncWaitMs=10000
-Dsun.java2d.noddraw=true
-Dsun.java2d.d3d=false
-Djdk.home=C:\Arquivos de programas\Java\jdk1.7.0_01
[code]
no qual Xmx esta muito baixo isso esta errado?
Um tempo atrás, eu estava desenvolvendo um trabalho na faculdade para ordenar valores
usando alguns algoritmos de ordenação e sempre dava erro de estouro de memória.
Quando eu aumentei o Xmx para 1024 resolveu meu problema.
O fato é que eu estava tentando ordenar uma quantidade muito elevada de valores(alguns milhões) usando o MergeSort e o limite default de memória não foi suficiente para rodar a aplicação.
No NetBeans, você pode configurar esse valor diretamente pelas propriedades do projeto.
Me corrijam se eu estiver errado.
Oi.
Se levarmos em conta questões de processamento entre outras, não é recomendável que o XMS seja diferente do XMX.
O motivo é que quando há essa diferença, o JVM processo o seu algoritmo e começa a alocar mais memória, e mais memória até que chegue ao XMX (ou não).
Isso pode se tornar um problema, se pensarmos em algoritmos que já exigem mais memória de processamento.
Entenda algo, o que é pouco ? 256 MB é pouco ? A palavra correta é “depende”. Você precisa mais do que isso para um algoritmo de perguntas, como aqueles que costumam passar na primeira aula de programação ? Mas enfim, é o default e para isso basta que você altere as configurações de sua JVM.
Abraços.
[quote=Jemerson]Um tempo atrás, eu estava desenvolvendo um trabalho na faculdade para ordenar valores
usando alguns algoritmos de ordenação e sempre dava erro de estouro de memória.
Quando eu aumentei o Xmx para 1024 resolveu meu problema.
O fato é que eu estava tentando ordenar uma quantidade muito elevada de valores(alguns milhões) usando o MergeSort e o limite default de memória não foi suficiente para rodar a aplicação.
No NetBeans, você pode configurar esse valor diretamente pelas propriedades do projeto.
Me corrijam se eu estiver errado.
[/quote]
Passei há um tempo atrás pelo mesmo Problema. Perceba que o aumento de memória para 1024 pode resolver o Problema paliativamente, de repente causando um estouro quando sua aplicação escalar.
Melhor do que sempre escalar os servidores para resolver o problema de falta de memória, é melhorar a performance da sua aplicação, a fim de evitar também desperdício de memória com uma aplicação que pode ser bem mais rápida.
Há duas formas de fazer isso:
1 - No código.
Lembre, seus Objetos ocupam espaço físico, suas variáveis Státicas, suas Strings, etc… Tudo o que você puder fazer para diminuir esse espaço se beneficiando do Garbage Collector, que mata esses objetos, ajudará sua aplicação a usar menos memória.
Aqui há uma excelente explicação sobre o assunto: http://www.arquiteturajava.com.br/livro/principios-de-garbage-collection.pdf
2 - Fazendo Tunning da JVM.
A Oracle disponibiliza um Documento oficial de todas as versões do Java sobre os parâmetros oficiais da JVM HotSpot e o que eles influenciam no comportamento da JVM e da vida dos Objetos.
Acho que falta (pelo menos nunca conheci) um profissional que fosse o Ninja da performance, tanto da JVM quanto via código. Não sei se o Arquiteto Java é esse cara, mas os Arquitetos que conhecí até hoje, não eram os feras nesse assunto, a maioria vinha com a solução de aumentar memória.
Enfim, procure informações sobre Tunning da JVM e aprenda a resolver os problemas de memória de forma eficiente, pra não recorrer ao erro de sempre que estourar a memória, a única solução ser aumentar.
Abs []