Comment résoudre une erreur Out-of-Memory dans Maximo JVM

Erreur OutOfMemory

Il arrive parfois que Maximo devienne indisponible pendant 5 à 10 minutes. Les alarmes sont déclenchées, le service d'assistance informatique est contacté, et le problème est escaladé au spécialiste Maximo (vous). En consultant les journaux, vous trouvez une erreur Out-of-Memory (OOM). Le serveur redémarre généralement de lui-même et redevient fonctionnel. Cependant, si ce problème se reproduit, il devient un incident critique nécessitant une analyse approfondie pour identifier la cause racine et éviter qu'il ne se reproduise. Voici une méthode pour traiter ce problème.

Fichiers de vidage Websphere

Par défaut, lorsqu'une erreur OOM survient, Websphere génère plusieurs fichiers de vidage dans le dossier [WAS_HOME]/profiles/<ProfileName>/. Ces fichiers incluent :

1. Javacore.[timestamp].txt

   • Contient des informations générales sur la JVM au moment du crash.
   • Peu utile pour les problèmes OOM, sauf si la cause n'est pas connue.

2. Heapdump.[timestamp].phd

   • Représente le contenu de la mémoire heap de la JVM.
   • Ce fichier est essentiel pour analyser les problèmes OOM.

3. Core.[timestamp].dmp

   • Vidage de mémoire native.
   • Peut être utile dans certains cas spécifiques, mais est souvent ignoré.

Outils pour analyser les vidages

• IBM Heap Analyzer (via IBM Support Assistant Workbench) pour les fichiers PHD.
• Windows Debugger Tool (WinDbg) pour les fichiers DMP sur Windows.

Études de cas

Cas 1 : Crash dû au chargement de données incorrectes via MXLoader

• Symptômes : Une JVM d'intégration a crashé lors du chargement de 1,6 Go de données (68 % de la mémoire allouée).
• Analyse :
  • Heap Analyzer a révélé une erreur StackOverflowError consommant 20 % de la mémoire.
  • Les journaux montraient des activités élevées d'un utilisateur spécifique avant le crash.
• Solution :
  • Former l'utilisateur sur l'utilisation de MXLoader.
  • Renforcer les paramètres d'intégration et de performance de Maximo.

Cas 2 : Crash dû à DbConnectionWatchDog

• Symptômes : Plusieurs crashs en peu de temps. Le fichier de vidage montrait un objet char[] occupant 40 % de la mémoire.
• Analyse :
  • Utilisation de WinDbg pour inspecter le contenu de l'objet.
  • L'objet contenait une accumulation de messages d'erreur de DbConnectionWatchDog, activé récemment pour diagnostiquer des problèmes de connexions.
• Solution :
  • Désactiver DbConnectionWatchDog, qui provoquait lui-même des problèmes.

Cas 3 : Crash dû à une fuite de mémoire

• Symptômes : Les JVM de l'interface utilisateur crashaient toutes les 2-3 semaines.
• Analyse :
  • Heap Analyzer identifiait des fuites liées à l'objet WebClientSessions.
  • Les journaux montraient un nombre anormalement élevé de WebClientSessions créés, bien plus que le nombre d'utilisateurs connectés.
  • Un paramètre Memory-to-Memory Replication dans Websphere était activé. Ce paramètre n'est pas pris en charge par Maximo.
• Solution :
  • Désactiver la réplication mémoire à mémoire dans Websphere.

Conclusion

Diagnostiquer une erreur Out-of-Memory dans Maximo n'est pas toujours simple. Avec les bons outils, une approche méthodique et une collaboration étroite avec les équipes internes et externes (y compris IBM Support), il est possible d'améliorer vos chances de succès pour résoudre ce problème. Partager des expériences similaires peut aider d'autres personnes confrontées à des défis similaires.