Consumo de memória JVM


9

Estou tentando executar o tomcat em um sistema com pouca memória (150-256Mb). Mesmo iniciando a JVM com -Xmx64m (que deve ser o padrão de qualquer maneira), o processo ocupa imediatamente 200Mb +.

Gostaria de saber por que a JVM precisa de tanta memória em si, ou se existe uma maneira de ajustar isso? Outras JVMs são melhores que a Sun para baixo consumo de memória - e elas funcionam com o tomcat?

Respostas:


5

Além da pilha (especificada por -Xmse -Xmx), você precisa incluir as áreas que não são da pilha. Esses incluem

  • O Perm Gen, que é de 64 MB em sistemas de 32 bits e 96 MB em sistemas de 64 bits inicialmente
  • O Cache de Código, que está entre 20 e 40mb, dependendo da JVM
  • A área do buffer NIO (de onde DirectByteBuffersão extraídos), inicialmente é de 64 mb

Há também o espaço de trabalho da própria JVM, que terá algumas dezenas de mb.

Você também deve estar ciente do dimensionamento automático da Sun JVM ao usar uma máquina de classe de servidor . Com o tempo, a definição de classe de servidor (memória de 2 GB, mais de um núcleo) sofreu alguma depreciação e agora a maioria das máquinas é capaz de acionar as -serverotimizações. Meu conselho é sempre para especificar os -Xmse -Xmxconfigurações e passar -servera menos que você pode pensar em uma boa razão não muito.


Cuidado também com a memória virtual que a JVM reserva apenas e ainda não usa.
Steve Schnepp

É verdade que a maioria desses segmentos, como o PermGen e o cache de código, são alocados na inicialização, mas a maioria dos kernels evita alocar páginas a esses segmentos até que seja necessário.
Dave Cheney

1
Obrigado pela informação - acho que isso explica para onde está indo a memória. Existe alguma maneira de alterar esses valores? Melhor ainda seria uma maneira de ver quanto de cada seção estava em uso - não sei se alguma das ferramentas de depuração / monitoramento Java permite fazer isso?
313 Draemon

1
Você pode usar pmap ou jmap para ter uma idéia sobre os vários segmentos em uso. A maioria das opções comuns (e seus padrões) estão listadas aqui, java.sun.com/javase/technologies/hotspot/vmoptions.jsp . Eles mudam frequentemente e estão sujeitas a diferenças de OS (tamanho da pilha geralmente) e do arco (SO de 64 bits é geralmente implicam maiores áreas JVM)
Dave Cheney

3

Com a opção -Xmx, você restringe o tamanho do heap que a JVM reserva ... Existem recursos adicionais que a JVM precisa ...

"Obrigado pela memória" * é um bom artigo que explica como uma JVM usa memória ...

Além disso, você pode tentar a JVM da IBM, que deve funcionar com o Tomcat, não sei se algumas das implementações gratuitas da JVM funcionam.

No entanto, não acho que uma máquina com memória tão baixa faça bem a você. Java só precisa de memória.

* Como os novos usuários não podem enviar hiperlinks, você mesmo deve procurar esse artigo ... é o primeiro hit do google por "obrigado pela memória ibm".


3
ibm.com/developerworks/java/library/j-nativememory-linux - Link para o artigo "Obrigado pela memória"
StackKrish


0

Uma técnica útil que encontrei é usar o monitoramento JMX para ver exatamente quanta memória é usada pelo espaço heap vs permgen.

Configure o JMX no Tomcat conforme descrito aqui http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html

Em seguida, use o JConsole (fornecido com o JDK 5 ou JDK 6) - o tag de memória acompanhará o consumo de memória ao longo do tempo.

Também - cuidado com reinicializações suaves de aplicativos da web. Se você recarregar um aplicativo da web, o espaço permgen não será coletado como lixo e será acumulado ao longo do tempo. Você precisa fazer uma parada / partida completa do Tomcat para recuperar o espaço permgen.


O VisualVM também pode ser usado em vez do JConsole e fornece ainda mais detalhes ao procurar problemas de memória na JVM. Eu tive que usar isso em mais de uma ocasião para encontrar problemas.
21139 Jeremy Bouse
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.