|
Java parametros xms e xmx |
|
Origem do texto abaixo resposta de forum: http://javafree.uol.com.br/topic-6735-StackOverflowError.html
"
Olha, a JVM tem três áreas básicas de memória: área do carregamento de classes, a Stack (pilha) e o Heap (área de objetos).
A única área que podemos configurar diretamente (que eu conheça) na JVM da Sun é o tamanho do heap (permitindo que "caibam" mais objetos na memória).
Podemos configurar a área mínima e máxima (sim, é até aconselhável fazer isso, vou explicar porque). Para área mínima, usamos -Xmsnm (onde "n" é a memória, em Mb, que queremos estabelecer) e para máxima usamos -Xmxnm (onde "n" é a memória máxima para o heap, em Mb). Exemplo:
- java -Xms64m -Xmx128m SuaAplicacao
Configura uma JVM com mínimo de 64Mb e máximo de 128Mb no Heap.
O default é 32Mb/32Mb, acho.
Pq mexer nessa configuração? Bem, o maior motivo é o funcionamento do GC Garbage Collector. Existem dois momentos importantes onde a JVM roda uma verificação pra saber se deve fazer a coleta de lixo: quando o heap ultrapassa o limite mínimo e quando o Heap está próximo do limite máximo.
Quando a coleta de lixo é executada, toda a JVM precisa fazer uma pequena "parada". Considere isso como uma "parada nos boxes" na fórmula 1... :oops: Por isso o GC não é executado toda hora. Agora veja, se o heap ultrapassa o limite mínimo e é elígível rodar o GC, o "pit stop" é feito e não precisa ser repetido por um bom tempo. Se não é possível rodar o GC neste momento, ele ainda terá uma outra oportunidade (quando chegar perto do limite máximo).
Assim:
-
- memória máxima (mx) -------------------------------------------x-(gc ) -
- x x
- x x
- x x
- memória mínima (ms) ----x-(gc)--x--(nogc)---x-------------------------
- xx x x
- x x x
Se a memória mínima e máxima são configuradas como iguais (como default) não haverá essa segunda oportunidade. A JVM precisará rodar o GC seja lá o que for que estiver fazendo, sob pena de um OutOfMemory! Quando isso acontecer, a JVM deverá se livrar de toda uma enormidade de objetos já acumulados no heap!
De onde concluímos que a performance fica muito melhor (na maioria das situações) quando temos a memória mínima e a memória máxima configuradas com valores diferentes. Isso dá uma chance da JVM fazer uma "pré-coleta" dos objetos mais voláteis no pico de memória mínima.
Uma ótima forma de aprender sobre isso é usando o JEdit e o plugin "JVM stats" :-)
Lendo isso, vc. vai se perguntar: "Mas qual a melhor configuração de memória pra JVM?". Sim, isso não é realmente muito intuitivo (toda empresa deveria ter um profissional especializado em manter seu servidor de aplicações dentro do melhor tunning). Uma boa notícia é que o Java 1.5 propõe uma JVM que se configura automaticamente de acordo com a necessidade! 8) Então essas dicas são úteis principalmente para a configuração de JVM 1.4.
[]s :!:
"
|
