Erreur de permGen dans Tomcat

Je travaille dans l’environnement Windows. Et je reçois cette erreur à chaque fois que je travaille avec tomcat

Apr 30, 2012 5:30:37 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet default threw exception java.lang.OutOfMemoryError: PermGen space 2012-04-30 17:30:37.719 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@4ae53a99 2012-04-30 17:30:37.719 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to failure to connect to {QA sa=localhost/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interestd=0} java.net.ConnectException: Connection refused: no further information Apr 30, 2012 5:30:37 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet default threw exception java.lang.OutOfMemoryError: PermGen space Exception in thread "Memcached IO over {MemcachedConnection to localhost/127.0.0.1:11211}" java.lang.OutOfMemoryError: PermGen space Apr 30, 2012 5:30:38 PM org.apache.coyote.http11.Http11Processor process SEVERE: Error processing request java.lang.OutOfMemoryError: PermGen space Apr 30, 2012 5:30:38 PM org.apache.coyote.http11.Http11Processor process SEVERE: Error processing request java.lang.OutOfMemoryError: PermGen space Apr 30, 2012 5:30:38 PM org.apache.coyote.http11.Http11Processor process SEVERE: Error processing request java.lang.OutOfMemoryError: PermGen space Apr 30, 2012 5:30:41 PM org.apache.catalina.connector.CoyoteAdapter service SEVERE: An exception or error occurred in the container during the request processing java.lang.OutOfMemoryError: PermGen space Apr 30, 2012 5:30:43 PM org.apache.catalina.core.StandardHostValve custom SEVERE: Exception Processing ErrorPage[exceptionType=java.lang.Throwable, location=/error.action] java.lang.OutOfMemoryError: PermGen space Apr 30, 2012 5:30:42 PM org.apache.catalina.core.StandardHostValve custom SEVERE: Exception Processing ErrorPage[exceptionType=java.lang.Throwable, location=/error.action] java.lang.OutOfMemoryError: PermGen space Exception in thread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" java.lang.OutOfMemoryError: PermGen space 

J’ai essayé d’append JAVA_OPTS with the value as -Xms1024m -Xmx1024m dans les variables système, JAVA_OPTS with the value as -Xms1024m -Xmx1024m toujours la même erreur (java.lang.OutOfMemoryError: PermGen space) . Toute aide serait appréciée. J’ai également lu d’autres articles dans stackoverflow mais cela n’a pas fonctionné.

L’espace PermGen est ce que Tomcat utilise pour stocker les définitions de classe (définitions uniquement, pas d’instanciations) et les pools de chaînes qui ont été internés. D’expérience, les problèmes d’espace PermGen ont tendance à se produire fréquemment dans les environnements de développement, car Tomcat doit charger de nouvelles classes chaque fois qu’il déploie un WAR ou effectue un jspc (lorsque vous modifiez un fichier jsp). Personnellement, j’ai tendance à déployer et à redéployer beaucoup les guerres lorsque je suis en test de développement, donc je sais que je vais devoir les épuiser tôt ou tard (principalement parce que les cycles GC de Java sont encore un peu compliqués, si vous redéployez vos guerres rapidement et fréquemment) assez, l’espace se remplit plus vite qu’ils ne peuvent gérer.

Cela devrait théoriquement être moins problématique dans les environnements de production puisque vous (espérons-le) ne changez pas la base de code sur 10 minutes. Si cela se produit encore, cela signifie simplement que votre base de code (et les dépendances de la bibliothèque correspondantes) sont trop volumineuses pour l’allocation de mémoire par défaut et qu’il vous suffira de modifier l’allocation de la stack et du tas. Je pense que les normes sont des choses comme:

 -XX:MaxPermSize=SIZE 

J’ai toutefois trouvé que le meilleur moyen de prendre soin de cela est de permettre aux classes d’être déchargées pour que votre PermGen ne s’épuise jamais:

 -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled 

Des trucs comme ça ont fonctionné de manière magique pour moi par le passé. Une chose, il y a un compromis de performance important dans l’utilisation de ceux-ci, puisque les balayages de permgen feront comme 2 demandes supplémentaires pour chaque demande que vous faites ou quelque chose dans ce sens. Vous devrez équilibrer votre utilisation avec les compromis.

Vous devez allouer plus d’espace au PermGenSpace de la machine virtuelle Java tomcat.

Cela peut être fait avec l’argument JVM: -XX: MaxPermSize = 128m

Par défaut, l’espace PermGen est 64M (et il contient toutes les classes compilées, donc si vous avez beaucoup de jar (classes) dans votre chemin de classe, vous pouvez en effet remplir cet espace).

Sur une note de côté, vous pouvez surveiller la taille de l’espace PermGen avec JVisualVM et vous pouvez même inspecter son contenu avec YourKit Java Profiler

Pour compléter la réponse de Michael, et selon cette réponse , un moyen sûr de résoudre le problème consiste à utiliser les arguments suivants:

 -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+UseConcMarkSweepGC 

Si tomcat s’exécute en tant que service Windows, CATALINA_OPTS et JAVA_OPTS ne semblent pas avoir d’effet.

Vous devez le définir dans les options Java dans l’interface graphique.

Le lien ci-dessous explique bien

http://www.12robots.com/index.cfm/2010/10/8/Giving-more-memory-to-the-Tomcat-Service-in-Windows

Celle-ci a fonctionné pour moi, dans startup.bat la ligne suivante doit être ajoutée si elle n’existe pas, set JAVA_OPTS avec la valeur -Xms128m -Xmx1024m -XX:PermSize=64m -XX:MaxPermSize=256 . La ligne complète:

 set JAVA_OPTS=-Dfile.encoding=UTF-8 -Xms128m -Xmx1024m -XX:PermSize=64m -XX:MaxPermSize=256 

Dans Tomcat 7.0 version du programme d’installation de Windows. Il n’y a pas catalina.bat dans / bin. Donc, vous devez ouvrir Tomcat7w.exe dans / bin et append un argument JVM

 -XX:PermSize=256m -XX:MaxPermSize=512m 

sur Java en Java, comme ceci. Vous ajoutez également d’autres options.

entrer la description de l'image ici

Un autre, si vous utilisez IntellijIDEA, vous devez append un argument JVM dans les configurations de serveur, comme ceci.

entrer la description de l'image ici

Le code de ligne de @AndreSmiley a fonctionné pour moi.

seule modification requirejse est.

-XX: MaxPermSize = 256 m

“m” signifie MB.

En fait, mon application est un peu énorme et on m’a conseillé de faire 1024m pour la performance.

J’utilise tomcat7 sur CentOS 6.6. J’ai essayé de créer un nouveau fichier /usr/share/tomcat/bin/setenv.sh et de définir à la fois JAVA_OPTS et CATALINA_OPTS . Mais Tomcat ne reprendrait pas les valeurs au redémarrage. Lorsque je mets la ligne suivante dans /etc/tomcat/tomcat.conf:

 CATALINA_OPTS="-Xms128m -Xmx1024m -XX:MaxPermSize=1024m" 

Tomcat a bien pris la nouvelle variable d’environnement. Je l’ai vérifié en courant

ps aux | grep tomcat

et voir les nouveaux parameters dans la sortie. Cela a pris beaucoup de temps à diagnostiquer et je n’ai vu personne suggérer cela, alors j’ai pensé le lancer à la communauté Internet.

Si vous utilisez eclipse avec tomcat suivez les étapes ci-dessous

  1. Sur la fenêtre du serveur Double-cliquez sur tomcat, cela ouvrira la fenêtre de présentation de tomcat.

  2. Dans la fenêtre Aperçu, vous trouverez la configuration de lancement ouverte sous Informations générales et cliquez sur Ouvrir la configuration de lancement .

  3. Dans la fenêtre Modifier la configuration, recherchez les arguments et cliquez dessus.
  4. Dans la balise arguments, recherchez les arguments VM .
  5. il suffit de coller -Xms256m -Xmx512m -XX: PermSize = 256m -XX: MaxPermSize = 512m à la fin des arguments.

modifier les propriétés de configuration du lancement

J’ai essayé la même chose sur Intellij Ideav11.

Il ne prenait pas les parameters après avoir vérifié le processus en utilisant grep. Dans le cas contraire, indiquez les parameters mem pour JAVA_OPTS dans catalina.sh.

Tuer le processus tomcat (avec force, tuer -9 pour Linux) et le redémarrer résout le problème. Je pense que l’instance tomcat n’est pas détruite correctement avec shutdown.bat. Donc, nous devons tuer le processus avec force et recommencer.