problèmes PermGen avec ascenseur et Jetty

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

Question

Je développe sur la plate-forme standard de levage (maven et jetée). Je suis à plusieurs reprises (une fois tous les deux jours) obtenir ceci: 

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

Ceci est dans mon environnement de dev. Ce n'est pas un problème parce que je peux continuer à redémarrer le serveur. Dans le déploiement Je ne suis pas avoir ces problèmes il est donc pas un vrai problème. Je suis juste curieux.

Je ne sais pas trop sur la machine virtuelle Java. Je pense que je suis raison de penser que la mémoire de génération permanente est pour des choses comme les classes et les chaînes internées? Ce que je me souviens est un peu mélangé avec le modèle de mémoire .NET ...

Toute raison pour laquelle cela se passe? Les valeurs par défaut juste crazily bas? Est-il à voir avec tous les objets auxiliaires que Scala doit créer des objets de fonction et les choses semblables FP? Chaque fois que je redémarre la jetée avec le code nouvellement écrit (toutes les quelques minutes) je l'imagine rechargements des classes etc. Mais même ainsi, il ne peut pas » être que beaucoup peut-il? Et ne devrait pas la machine virtuelle Java capable de traiter un grand nombre de classes?

Vive

Joe

Était-ce utile?

La solution

De ce message :

  

Cette exception a eu lieu pour une raison simple:
   permgenspace est où les propriétés de classe, telles que les méthodes, les champs, les annotations, ainsi que les variables statiques, etc. sont stockés dans la machine virtuelle Java, mais cet espace a la particularité de ne pas être nettoyé par le collecteur des ordures .   Donc, si votre webapp utilise ou crée beaucoup de classes (je pense à des générations dynamiques de classes), les chances sont que vous rencontré ce problème.   Voici quelques solutions qui me ont aidé à se débarrasser de cette exception:

  • -XX:+CMSClassUnloadingEnabled: ce paramètre permet la collecte des ordures dans le permgenspace
  • -XX:+CMSPermGenSweepingEnabled: permet au collecteur d'ordures pour enlever même les classes de la mémoire
  • -XX:PermSize=64M -XX:MaxPermSize=128M: augmente la quantité de mémoire allouée à la permgenspace

Peut-être cela pourrait aider.

Modifier Juillet 2012 (presque 3 ans plus tard):

Ondra Žižka commentaires (et je l'ai mis à jour la réponse ci-dessus):

  

machine virtuelle Java 1.6.0_27 dit: S'il vous plaît utiliser:

  • CMSClassUnloadingEnabled (Que le déchargement de la classe activée lors de l'utilisation CMS GC)
  • à la place de CMSPermGenSweepingEnabled à l'avenir

Voir toute Hotspot JVM Options -. de référence complet pour mroe

Autres conseils

Si vous voyez ce mvn jetty:run lors de l'exécution, régler le MAVEN_OPTS.

Pour Linux: 

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

Pour Windows: 

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

Doit être bien maintenant. Dans le cas contraire, augmenter -XX:MaxPermSize.

Vous pouvez aussi mettre ces en permanence à votre environnement.

Ceci est dû à la rupture de charge des classes comme vous le suggérez. Si vous utilisez beaucoup de bibliothèques, etc. la somme des classes se développera rapidement pour chaque redémarrage. Essayez le suivi de votre instance de jetée avec VisualVM pour obtenir un aperçu de la consommation de mémoire lors du rechargement.

La liste de diffusion ( http://groups.google.com/group/liftweb/) est le forum de support officiel Lift, et où vous serez en mesure d'obtenir une meilleure réponse. Je ne connais pas les détails de la configuration de votre dev (vous n'allez pas dans les détails), mais je suppose que vous êtes rechargeant votre guerre jetée sans redémarrer réellement. Ascenseur ne fonctionne pas la génération de classe dynamique (comme suggéré par VonC ci-dessus), mais Scala compile chaque fermeture comme une classe distincte. Si vous ajoutez et la suppression des fermetures à votre code au cours de plusieurs jours, il est possible que trop de classes sont chargées et déchargées et ne prenant permgen. Je vous suggère d'activer les options options de JVM mentionnées par VonC ci-dessus et voir si elles aident.

La génération permanente est l'endroit où la machine virtuelle Java met des choses qui ne sera probablement pas (ordures) collectés comme classloaders personnalisés.

En fonction de ce que vous déployez, le réglage perm gen peut être faible. Certaines applications et / ou des conteneurs combinaison contiennent des fuites de mémoire, alors quand une application se parfois des trucs non déployé comme les chargeurs de classe ne sont pas collectées, ce qui remplit l'espace Perm générant ainsi l'erreur que vous rencontrez.

Malheureusement, actuellement la meilleure option dans ce cas est au maximum jusqu'à la permgen avec le drapeau jvm suivant (exemple pour 192m taille perm): 

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

L'autre option est de faire en sorte que soit le contenant ou le cadre ne fuient pas la mémoire.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top