Récupération de Java.lang.OutOfMemoryError: Java Heap space sur Jboss
Obtenir Java.lang.OutOfMemoryError: Java Heap space sur Jboss 7 L'entrée dans la configuration de jboss est
set "Java_OPTS=-Xms1G -Xmx2G -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=2096M"
L'erreur était
Java.lang.OutOfMemoryError: Java heap space
at Java.util.Arrays.copyOf(Arrays.Java:3332) [rt.jar:1.8.0_231]
at Java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.Java:124) [rt.jar:1.8.0_231]
at Java.lang.AbstractStringBuilder.append(AbstractStringBuilder.Java:448) [rt.jar:1.8.0_231]
at Java.lang.StringBuffer.append(StringBuffer.Java:270) [rt.jar:1.8.0_231]
at Java.io.StringWriter.write(StringWriter.Java:112) [rt.jar:1.8.0_231]
at Java.io.PrintWriter.write(PrintWriter.Java:456) [rt.jar:1.8.0_231]
at Java.io.PrintWriter.write(PrintWriter.Java:473) [rt.jar:1.8.0_231]
at Java.io.PrintWriter.print(PrintWriter.Java:603) [rt.jar:1.8.0_231]
at Java.io.PrintWriter.println(PrintWriter.Java:756) [rt.jar:1.8.0_231]
at Java.lang.Throwable$WrappedPrintWriter.println(Throwable.Java:765) [rt.jar:1.8.0_231]
at Java.lang.Throwable.printEnclosedStackTrace(Throwable.Java:698) [rt.jar:1.8.0_231]
at Java.lang.Throwable.printEnclosedStackTrace(Throwable.Java:710) [rt.jar:1.8.0_231]
Selon l'application déployée sur un JBoss, même 2 Go d'un tas pourraient ne pas suffire. Problèmes potentiels:
Xmxla configuration n'est pas appliquée (la configuration est effectuée dans un mauvais fichier)- L'application nécessite juste plus de tas
- Il y a une fuite de mémoire dans l'application
Si vous exécutez JBoss sous Windows, définissez dans standalone.conf.bat fichier dans le Java_OPTS variable les valeurs suivantes -Xmx2G -XX:MaxMetaspaceSize=1G.
standalone.conf est ignoré sous Windows et appliqué uniquement sur les systèmes * nix.
Vérifiez que ces valeurs sont appliquées en vous connectant à la JVM en utilisant JConsole (qui fait partie de JDK) ou JVisualVM .
En utilisant ces outils, vous pouvez surveiller l'utilisation du tas et voir si plus de tas est nécessaire.
Si la taille du tas est suffisamment grande (par exemple 4+ Go) et que le tas augmente constamment alors que le garbage collection (GC) ne libère pas d'espace, il y a probablement une fuite de mémoire.
Pour l'analyse, ajoutez à la Java_OPTS les indicateurs suivants: -Xloggc:gc.log -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError.
Avec ces indicateurs, JVM enregistrera l'activité du GC dans le gc.log fichier où vous pouvez voir explicitement combien d'espace est libéré après le GC.
Si les exécutions ultérieures de GC selon le journal ne libèrent aucun espace, il y a probablement une fuite de mémoire et vous devriez analyser un vidage de tas créé manuellement à l'aide de JVisualVM ou créé par JVM lui-même sur OutOfMemoryError. Les vidages de tas peuvent être analysés à l'aide de JVisualVM ou Eclipse Memory Analyzer (MAT) .
En général, cette erreur est générée lorsqu'il n'y a pas suffisamment d'espace pour allouer un objet dans le tas Java). Dans ce cas, le ramasse-miettes ne peut pas libérer de l'espace pour accueillir un nouvel objet, et le tas ne peut pas être élargi davantage.
Veuillez suivre les étapes possibles ci-dessous pour réparer Java.lang.OutOfMemoryError.
Étape 1: Vérifiez les paramètres de configuration de JBoss. Le paramètre dépend de la configuration de votre système, Java et version JBoss. Vérifiez la configuration ici .
Étape 2: Vérifiez les paramètres de vidage du tas ici .
Étape 3: Java code/problème de bibliothèque.
Analysez votre mémoire ici Et profileur de mémoire Jboss .
Les autres causes de ce message OutOfMemoryError sont plus complexes et sont causées par une erreur de programmation.
Java.lang.OutOfMemoryError : OutOfMemoryError signifie généralement que vous faites quelque chose de mal, soit un problème de configuration (où la taille de tas spécifiée est insuffisante pour l'application) ou retenir les objets trop longtemps (cela empêche les objets d'être ramassés), ou essayer de traiter trop de données à la fois.
Solutions possibles:
1) Essayez de définir "Java_OPTS = -Xms1G -Xmx1G -XX: MaxPermSize = 256M" sur la valeur maximale et redémarrez votre serveur.
2) Vérifiez votre code pour toute fuite de mémoire. Utilisez un lecteur de vidage de tas pour vérifier la même chose. (Il existe plusieurs plugins disponibles pour les IDE comme Eclipse, IntelliJ, etc.)
3) Vérifiez votre code (90% des problèmes de temps sont dans le code): Vérifiez si vous chargez des données en excès à partir d'une base de données ou d'une autre source dans votre mémoire de tas et si c'est vraiment nécessaire. Si vous appelez plusieurs services Web et plusieurs opérations en lecture seule de base de données, vérifiez la requête db (si les jointures sont parfaitement utilisées avec les clauses right where) et la quantité de données renvoyées par la requête db et le service Web.
4) Si le problème est dû à une modification récente du code, essayez de l'analyser.
5) Vérifiez également si les éléments du cache et de la session sont effacés une fois utilisés.
6) Pour être sûr que le problème n'est pas dû à Jboss, vous pouvez exécuter le même code sur un autre serveur à des fins de test (Tomcat, Websphere, etc.)
7) Consultez Java pour plus de compréhension sur l'erreur de manque de mémoire: lien de documentation
Assurez-vous d'avoir fourni suffisamment d'espace dans votre standalone.conf fichier dans bin directory
Java_OPTS="-Xms512m -Xmx1024m -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=1024m -Djava.net.preferIPv4Stack=true"
Vous devriez avoir à augmenter MaxMetaSpaceSize jusqu'à 1024m et MetaspaceSize à 256m espérons que cela fonctionnera.
Essayez également de surveiller votre processus, essayez d'exécuter jvisualvm (est inclus dans le jdk) et une interface utilisateur s'ouvrira, à partir de là, vous pourrez obtenir beaucoup d'informations.
J'espère que cela vous aidera.