Analyser des problèmes de mémoire

Découvrez comment identifier la cause des problèmes de mémoire de l’application Java. Vous pouvez générer une image mémoire automatiquement et manuellement, ainsi qu’un histogramme des segments de mémoire, pour identifier la cause.

Description description

Environnement

Experience Manager

Problème/Symptômes

L’application JAVA s’exécute plus lentement et finit par manquer de mémoire ou une erreur s’affiche dans les journaux ou dans le OutOfMemoryError: Java heap space ou le OutOfMemoryError: gc overhead limit exceeded de sortie de la console.

Résolution resolution

Cause
De tels problèmes peuvent avoir de nombreuses causes.

L’une des causes possibles est que l’application Java , dans notre cas CRX/CQ, a été démarrée à partir de la ligne de commande avec les paramètres de mémoire de segment par défaut de Java. Cela signifie que le paramètre jvm -Xmx n’a pas été spécifié. CRX ou CQ ont besoin d’au moins 256 Mo de segments alloués pour s’exécuter. S’il s’agit bien de ce problème, assurez-vous que les paramètres de mémoire de segment sont définis à partir de la ligne de commande. Exemple :

java -Xmx512m -jar *.jar

Si ce n’est pas le cas, votre application peut conserver trop d’objets sans les libérer pour la récupération de l’espace mémoire. Cela s’appelle une fuite de mémoire. Voir ici pour plus d’informations. Consultez la section ci-dessous sur l’analyse des problèmes de mémoire dans les applications Java. Créer une image mémoire:

Générer automatiquement une image mémoire

Pour créer automatiquement une image mémoire en cas de manque de mémoire, vous pouvez ajouter le paramètre jvm -XX:+HeapDumpOnOutOfMemoryError pour générer automatiquement une image mémoire lorsque l’application renvoie une erreur OutOfMemory. Par exemple,

java -Xmx256m -XX:+HeapDumpOnOutOfMemoryError -jar *.jar

Cela génère un fichier d’image mémoire (java_...hprof) dans le répertoire de travail du processus chaque fois que le processus Java manque de mémoire. celui-ci peut continuer à s’exécuter une fois l’image mémoire générée. En règle générale, un fichier d’image mémoire suffit à analyser le problème.

Remarque : si vous utilisez le script crx-quickstart/server/start pour démarrer votre instance CRX, vous pouvez ajouter -XX:+HeapDumpOnOutOfMemoryError à la variable CQ_JVM_OPTS (vérifiez que cette variable n’est pas non plus commentée). Par exemple :

CQ_JVM_OPTS='-XX:+HeapDumpOnOutOfMemoryError'

Après avoir ajouté ce paramètre et redémarré l’instance CRX, vérifiez que la nouvelle option jvm est définie. Exécutez ps -ef | grep java à partir de la ligne de commande. Vérifiez ensuite si vous voyez -XX:+HeapDumpOnOutOfMemoryError comme paramètre du processus Java CRX.

Si vous devez spécifier un autre répertoire pour générer l’image mémoire en raison de restrictions d’espace disque, vous pouvez ajouter le paramètre -XX:HeapDumpPath=/path/to/generate/heapdump pour indiquer au jvm où placer le fichier.

Voir ici pour obtenir une référence des paramètres jvm liés au débogage. Générer manuellement une image mémoire JVM Sun/Oracle

Pour générer manuellement une image mémoire, exécutez cette commande (vous trouverez jmap et jps dans le dossier bin de votre répertoire racine jdk) :

IBM JVM

Vous devrez d’abord modifier les paramètres JVM par défaut concernant les agents de vidage pour générer les vidages corrects sur le signal de l’utilisateur. Il existe plusieurs types de vidage, mais vous avez généralement besoin du  vidage du système  complet pour effectuer une analyse approfondie de la mémoire. Ajoutez les arguments suivants :

Xdump:heap:opts=PHD+CLASSIC:events=user -Xdump:system:events=user

Cet événement « utilisateur » se produit lorsque l’environnement JVM reçoit le signal SIGQUIT (Linux, AIX®, z/OS® et i5/OS™) ou SIGBREAK (Windows) du système d’exploitation.

Pour plus d’informations, consultez la documentation fournisseur disponible ici.

Avertissement : les fichiers d’image mémoire sont volumineux et peuvent atteindre la même taille sur le disque que votre configuration de paramètre jvm heap -Xmx maximale. Assurez-vous que l’espace disque alloué au répertoire dans lequel le fichier de vidage est généré est suffisant. Analyser l’image mémoire
Un bon outil pour analyser les vidages de tas est EclipseMAT (Eclipse Memory Analyzer).

Cet outil ne peut pas analyser les vidages générés IBM JVM. Pour ceux-là, il y a plusieurs possibilités. IBM HeapAnalyzer s’en sortira bien pour les images mémoire au format PHD ou classique.
Pour une analyse complète de vidage du système, utilisez le Workbench de l’assistant de support IBM, avec les outils de surveillance et de diagnostic IBM pour Java - Memory Analyzer installés sur le dessus. L’histogramme du vidage est une mesure simple du nombre d’objets dynamiques et de la mémoire utilisée par classe Java. Malheureusement, en fonction de l’installation de Java, les outils requis peuvent ne pas être disponibles ou ne pas toujours fonctionner. Pour créer un histogramme de vidage, vous devez d’abord connaître l’ID du processus Java. Pour l’obtenir, exécutez ps or (if available), run:Histogramme du vidage
L’histogramme du vidage est une mesure simple du nombre d’objets dynamiques et de la mémoire utilisée par classe Java. Malheureusement, en fonction de l’installation de Java, les outils requis peuvent ne pas être disponibles ou ne pas toujours fonctionner. Pour créer un histogramme de vidage, vous devez d’abord connaître l’ID du processus Java. Pour l’obtenir, exécutez ps ou (le cas échéant), exécutez :

jps -l

Cet outil Java récupère les identifiants de processus de tous les processus Java en cours d’exécution. Exemple :

327
3332 sun.tools.jps.Jps
3313 crx-quickstart-....jar

À présent, exécutez la commande suivante :

jmap -histo 3313

La liste est triée en fonction de la mémoire totale requise (superficielle : à l’exception des objets référencés). Les 20 premières lignes de la sortie sont les plus intéressantes. Exemple de sortie :

JVM version is 1.5.0_20-141
Iterating over heap. This may take a while...
Warning: skipping invalid TLAB for thread t@62211
Warning: skipping invalid TLAB for thread t@62467
...
SizeCountClass description
-------------------------------------------------------
1059290412916byte`[` `]`
1028584075255* ConstMethodKlass
628317658388char`[` `]`
604230414928int`[` `]`
4995752116201* SymbolKlass
422089675255* MethodKlass
41965126969* ConstantPoolKlass
29285606969* InstanceKlassKlass
26310086066* ConstantPoolCacheKlass
2395872149742org.apache.jackrabbit.core.query.lucene.DocId$PlainDocId
14760087003java.util.HashMap$Entry`[` `]`
139612858172java.lang.String
107023244593java.util.HashMap$Entry
75398410036short`[` `]`
73546454org.apache.jackrabbit.core.query.lucene.DocId`[` `]`
7201927502java.lang.Class
64070413348com.day.crx.persistence.tar.index.IndexEntry
...

Informations supplémentaires

Pour vous aider à analyser le problème, nous devons également connaître les informations suivantes :

Références

[ 1 ] Guide de dépannage > Centre d’aide Oracle pour la machine virtuelle HotSpot
[ 2 ] Oracle.com > javas > DebuggingOptions