problemas permgen com elevador e Jetty

StackOverflow https://stackoverflow.com/questions/1451648

Pergunta

Estou desenvolvendo na plataforma de elevação standard (maven e cais). Tenho repetidamente (uma vez a cada dois dias) recebendo este: 

Exception in thread "7048009@qtp-3179125-12" java.lang.OutOfMemoryError: PermGen space
2009-09-15 19:41:38.629::WARN:  handle failed
java.lang.OutOfMemoryError: PermGen space

Este é no meu ambiente dev. Não é um problema, porque eu posso manter reiniciar o servidor. Na implantação Eu não estou tendo esses problemas, então não é um problema real. Eu sou apenas curioso.

Eu não sei muito sobre a JVM. Eu acho que estou correto em pensar que a memória geração permanente é para coisas como classes e cordas internados? O que me lembro é um pouco misturado com o modelo de memória .NET ...

Você tem algum motivo por que isso está acontecendo? São os padrões apenas loucamente baixo? É fazer com todos os objetos auxiliares que Scala tem que criar para objetos de função e coisas FP semelhantes? Toda vez que eu reiniciar Molhe com código recém-escrito (a cada poucos minutos) eu imagino que re-carrega as classes etc. Mas, mesmo assim, ele não pode' ser que pode muitos isso? E não deve a JVM ser capaz de lidar com um grande número de classes?

Felicidades

Joe

Foi útil?

Solução

A partir este post :

Esta exceção ocorreu por um simples motivo:
permgenspace é onde propriedades de classe, tais como métodos, campos, anotações, e também variáveis ??estáticas, etc. são armazenados no Java VM, mas este espaço tem a particularidade de não ser limpas pelo coletor de lixo . Portanto, se seus usos webapp ou cria um monte de aulas (estou pensando gerações dinâmicas de classes), as chances são que você encontrou este problema. Aqui estão algumas soluções que me ajudaram a se livrar dessa exceção:

  • -XX:+CMSClassUnloadingEnabled: essa configuração permite a coleta de lixo na permgenspace
  • -XX:+CMSPermGenSweepingEnabled: permite que o coletor de lixo para remover até mesmo aulas a partir da memória
  • -XX:PermSize=64M -XX:MaxPermSize=128M: aumenta a quantidade de memória alocada para o permgenspace

Pode ser este poderia ajudar.

Editar julho de 2012 (quase 3 anos depois):

Ondra Žižka comentários (e eu atualizei a resposta acima):

JVM 1.6.0_27 diz: use por favor:

  • CMSClassUnloadingEnabled (Se classe descarga habilitado ao usar CMS GC)
  • no lugar de CMSPermGenSweepingEnabled no futuro

Veja a plena Hotspot Opções de JVM -. O referência completa para mroe

Outras dicas

Se você ver isso ao executar mvn jetty:run, definir o MAVEN_OPTS.

Para Linux: 

export MAVEN_OPTS="-XX:+CMSClassUnloadingEnabled -XX:PermSize=256M -XX:MaxPermSize=512M"
mvn jetty:run

Para Windows: 

set "MAVEN_OPTS=-XX:+CMSClassUnloadingEnabled -XX:PermSize=256M -XX:MaxPermSize=512M"
mvn jetty:run

Deve ser bem agora. Se não, aumento -XX:MaxPermSize.

Você também pode colocá-los permanentemente para o seu ambiente.

Isto é devido a recarga de aulas como você sugeriu. Se você estiver usando várias bibliotecas etc. a soma das classes irá crescer rapidamente para cada reinicialização. Tente monitorar seu exemplo cais com VisualVM para obter uma visão geral do consumo de memória quando recarregar.

A lista de discussão ( http://groups.google.com/group/liftweb/) é o fórum de suporte oficial para o Levante, e onde você vai ser capaz de obter uma resposta melhor. Eu não sei os detalhes de sua configuração de dev (você não entrar em muitos detalhes), mas eu suponho que você está recarregando sua guerra no Jetty sem realmente reiniciá-lo. Elevador não realizar a geração de classe dinâmico (como sugerido por VonC acima), mas Scala compila cada fecho como uma classe separada. Se você está adicionando e removendo tampas para o seu código ao longo de vários dias, é possível que muitas classes estão sendo carregados e nunca descarregado e ocupando espaço perm. Eu sugiro que você ativar as opções de opções de JVM mencionados por VonC acima e ver se eles ajudam.

A geração permanente é onde as puts JVM coisas que provavelmente não vai ser (lixo) recolhidos como carregadores de classe personalizados.

Dependendo do que você está implantando, a configuração gen perm pode ser baixa. Algumas aplicações e / ou recipientes de combinação contêm alguns vazamentos de memória, por isso, quando um aplicativo é undeployed às vezes algumas coisas como carregadores de classe não são recolhidos, resultando em preenchendo o espaço Perm, assim, gerar o erro que você está tendo.

Infelizmente, atualmente a melhor opção neste caso é ao máximo o espaço perm com o seguinte sinalizador jvm (exemplo para o tamanho 192m perm): 

-XX:MaxPermSize=192M (or 256M)

A outra opção é ter certeza de que tanto a embalagem ou o quadro não vazar memória.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top