Java EE

Les erreurs "OutOfMemory" peuvent survenir sur différents serveurs d'application Java.
Leurs causes sont multiples:

• Saturation de la "java heap"

(zone mémoire dans laquelle sont stockés les objets créés par l'application java). Le message d'erreur retourné est alors:

Exception in thread ?main? java.lang.OutOfMemoryError: Java heap space

Il peut être résolu par un paramétrage de la JVM (-Xms -Xmx -Xss) au lancement de l'application (et éventuellement de la variable MAXDATA sur Aix)

• Saturation de la mémoire permanente

Message d'erreur:

java.lang.OutOfMemoryError: PermGen space

Résolu en augmentant Maxpermsize par l'option -XX:MaxPermSize
 

• Saturation de la "native heap"

Message d'erreur:

java.lang.OutOfMemoryError: request <size> bytes for <reason>. Out of swap space?

Il peut être dû à une taille de swap insuffisante de l'OS, ou à la présence sur le système d'autres process consommateurs de mémoire.
 

• Fragmentation de la heap (JVM IBM)

Corrigée par le positionnement des paramètres -Xk et -Xp

• Limitations des JVMs sur différentes plate-formes

Des limitations (et des problèmes) d'une JVM ont parfois été identifiés sur une plate-forme donnée. Elles sont alors décrites dans les "releases notes" ou les fichiers "README" livrés avec la JVM.

• Fuites mémoires applicatives

Ressources non libérées (connexions TCP non fermées par l'application, par exemple), allocation de gros objets, boucle sur l'allocation d'objets...

Recommandations

• Vérifier sa compatibilité (et limitations éventuelles) avec la plate-forme.

• Etudier le message d'erreur complet et la trace générés lors de l'exception afin de savoir quelle zone de la mémoire est impactée (heap, non heap), et éventuellement, la méthode responsable.
• Consulter la documentation de la JVM, afin de positionner le paramétrage adéquat (les options varient d'une JVM à l'autre).

• Dans tous les cas, un tuning sera nécessaire pour déterminer le paramétrage adapté à l'application:

Lancer l'application avec l'option java "-verbose:gc", de façon à tracer l'activité du Garbage Collector.
(Si verboseGC est positionné sans spécifier de fichier de log, les informations sont consignées dans stdout)

• Monitorer la mémoire en temps réel, avec les outils fournis par la JVM (et les commandes décrites dans les "Diagnostics Guide") :

Le site d'IBM propose un certain nombre d'outils de monitoring, dont GCDIAG et HEAPANALYZER.

La JVM ORACLE/SUN founit JCONSOLE (à partir de JDK5) et JVISUALVM (à partir de JDK6), des outils graphiques permettant le management et le monitoring des applications.

La JROCKIT apporte la JROCKIT MISSION CONTROLE (sous licence) qui regroupe un ensemble d'outils de management, monitoring et
profiling.

Documentation

JVM IBM:

- Getting more memory in AIX for your Java applications
(http://www-128.ibm.com/developerworks/eserver/articles/aix4java1.html)

- Fine-tuning Java garbage collection performance
(http://www-128.ibm.com/developerworks/ibm/library/i-gctroub/)

- diagnosis guide
(http://www-128.ibm.com/developerworks/java/jdk/diagnosis/)


JVM SUN:

- Trouble-Shooting and Diagnostic Guide (JVM 5.0)

- Troubleshooting Guide for JavaTM SE 6 with HotSpotTMVM

- Troubleshooting Guide for HotSpotTMVM (JDK7)

- http://java.sun.com/developer/technicalArticles/J2SE/monitoring/

- http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf


JRockit (Oracle/Bea)

- Diagnostics Guide (5.0)

 

Autres liens

- JOnAS: Erreur PermGen space après quelques déploiements

- Jonas et erreur OutOfMemoryError