tradeoff velocidade de opções -Xms e -Xmx do Java

Question

Tendo em conta estes dois comandos

A:

$ java -Xms10G -Xmx10G myjavacode input.txt

B:

$ java -Xms5G -Xmx5G myjavacode input.txt

Eu tenho duas perguntas:

1. Uma vez que as reservas comandar um mais memória com seus parâmetros, a vontade de um prazo mais rápido do que B?
2. Como -Xmx e -Xms afetar o processo de execução e a saída do meu programa?

Answer 1

Depende do GC seu java está usando. GCs paralelas pode funcionar melhor em configurações de memória maiores -. Eu não sou nenhum perito em que, embora

Em geral, se você tem maior quantidade de memória a menos freqüentes ele precisa ser GC-ed - há muito espaço para o lixo. No entanto, quando se trata de um GC, a GC tem que trabalhar em mais memória -. Que por sua vez pode ser mais lenta

Answer 2

O argumento -Xmx define o tamanho da memória máximo que a pilha pode chegar para o JVM. Você deve conhecer o seu programa de bem e ver como ele se comporta sob carga e definir este parâmetro em conformidade. Um valor baixo pode causar OutOfMemoryExceptions ou um desempenho muito pobre se memória heap do seu programa está atingindo o tamanho máximo de heap. Se o seu programa está sendo executado no servidor dedicado você pode definir este parâmetro maior, porque ele não vai afetar outros programas.

O argumento -Xms define o tamanho da memória heap inicial para a JVM. Isto significa que quando você iniciar o programa a JVM irá alocar esta quantidade de memória instantaneamente. Isso é útil se o seu programa vai consumir uma grande quantidade de memória heap desde o início. Isso evita a JVM a ser constantemente aumentando a pilha e pode ganhar algum desempenho lá. Se você não sabe se este parâmetro está indo para ajudá-lo, não usá-lo .

Em resumo, este é um compromisso que você tem que decidir com base apenas no comportamento da memória do seu programa.

Answer 3

Eu descobri que em alguns casos, muita memória pode tornar o programa lento.

Por exemplo, eu tinha uma hibernação com base transformar motor que começou a correr lentamente como a carga aumentou. Descobriu-se que cada vez que tem um objeto a partir do db, hibernate estava verificando a memória para objetos que nunca seriam utilizados novamente.

A solução foi expulsar os antigos objetos da sessão.

Stuart

Answer 4

1. Alocação sempre depende do seu sistema operacional. Se você alocar muita memória, você pode acabar tendo porções carregado no swap, que na verdade é lento.
2. se o seu programa é executado mais lento ou mais rápido depende das referências da VM tem de manusear e limpo. Será que o GC não tem que varrer a memória alocada para encontrar objetos abandonados. Ele sabe que é objetos e a quantidade de memória que alocar pelo mapeamento de referência. Então, varrendo só depende do tamanho de seus objetos. Se o seu programa se comporta da mesma em ambos os casos, o único impacto no desempenho deve ser na inicialização VM, quando o VM tenta alocar a memória fornecida pelo seu sistema operacional e se você usar o swap (que por sua vez leva a 1).

Answer 5

É difícil dizer como a alocação de memória irá afectar a sua velocidade. Depende do algoritmo de coleta de lixo da JVM está usando. Por exemplo, se suas necessidades coletor de lixo para fazer uma pausa para fazer uma coleção completa, em seguida, se você tiver mais de 10 memória do que você realmente precisa, em seguida, o coletor terá mais 10 lixo para limpar.

Se você estiver usando Java 6 você pode usar o jconsole (no diretório bin do JDK) para anexar ao seu processo e ver como o coletor está se comportando. Em geral, os coletores são muito inteligentes e você não vai precisar fazer qualquer ajuste, mas se você tem uma necessidade, existem inúmeras opções que você tem uso para ajusta ainda mais o processo de coleta.

Answer 6

> C:\java -X

-Xmixed           mixed mode execution (default)
-Xint             interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
                  set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
                  append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
                  prepend in front of bootstrap class path
-Xnoclassgc       disable class garbage collection
-Xincgc           enable incremental garbage collection
-Xloggc:<file>    log GC status to a file with time stamps
-Xbatch           disable background compilation
-Xms<size>        set initial Java heap size
-Xmx<size>        set maximum Java heap size
-Xss<size>        set java thread stack size
-Xprof            output cpu profiling data
-Xfuture          enable strictest checks, anticipating future default
-Xrs              reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni       perform additional checks for JNI functions
-Xshare:off       do not attempt to use shared class data
-Xshare:auto      use shared class data if possible (default)
-Xshare:on        require using shared class data, otherwise fail.

As opções -X são não-padrão e sujeito a alteração sem aviso prévio.

(copiar e colar)

Answer 7

Esta era sempre a pergunta que eu tinha quando eu estava trabalhando em um dos meu aplicativo que criou grande número de fios por pedido.

Portanto, esta é uma pergunta muito boa e há dois aspectos deste:
1. Se o meu valor Xms e Xmx deve ser o mesmo
- A maioria dos sites e documentos oracle mesmo sugerir que ele seja o mesmo. No entanto, sugiro que ter algum 10-20% de tampão entre esses valores para dar montão redimensionar uma opção para a sua aplicação no caso de picos repentinos alto tráfego ou um vazamento de memória incidental.
2. Se eu deveria começar minha aplicação com tamanho da pilha menor
- Então aqui está a coisa - não importa o que GC Algo que você usa (mesmo G1), grande pilha sempre tem algum comércio fora. O objetivo é identificar o comportamento de seu aplicativo para o tamanho da pilha você pode permitir que seus pausas do GC em termos de latência e taxa de transferência.
- Por exemplo, se a sua aplicação tem muitos tópicos (cada thread tem 1 MB de pilha na memória nativa e não na pilha), mas não ocupa espaço objeto pesado, então eu sugiro que tem um valor mais baixo de Xms.
- Se seu aplicativo cria muitos objetos com o aumento do número de threads, em seguida, identificar a que valor de Xms você pode definir a tolerar essas pausas STW. Isto significa identificar o tempo de resposta máximo de suas solicitações de entrada que você pode tolerar e ajustar de acordo com o tamanho da pilha mínimo.