Discussion :

[chouji77]

Bonjour,

Comment puis-je détecter depuis mon application si l'instance Tomcat fait de l'OutOfMemory (OOM) ou pas ?

Actuellement, je monitors mon applications en cherchant un mot clé dans une page.
Cette page réalise plusieurs contrôles internes et si l'application tourne bien, elle renvoie un statut valide. Et inversement en cas de problème.

Et il arrive que le Tomcat tombe en OOM (Java Heap full) - application down mais la page de monitoring fonctionne toujours -.
Pour pouvoir optimiser cette page de monitoring, je souhaiterai savoir si il possible de vérifier l'état de la mémoire depuis mon appli?


Dans un premier temps, j'ai essayé cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
double totalMem = Runtime.getRuntime().totalMemory();
double maxMem = Runtime.getRuntime().maxMemory();
double marge = 0.995; 
 
if(totalMem > ( maxMem * marge )){
	err = "Full memory";
}else{
	err = "RAS";
}

Et après test, c'est pas top. Certain moment, Tomcat utilise 100% de la mémoire mais il ne crache pas d'OOM et l'application fonctionne bien.

[tchize_]

un OOM ne veux pas dire que tomcat arrêt de fonctionner. Dans la majorité des cas, le OOM est du à une requete gourmande, donc c'est elle qui renvoie un OOM. Une fois la requête avortée, la mémoire est libérée et les autres requêtes continuent sans soucis. Par contre, si pendant cette requêt, quelqu'un essaie par exemple de charger une nouvelle classe dans le classloader et que ce chargement lance un OOM, cette classe sera définitivement inaccessible.

Ce qu'il te faut faire

1) identifier la cause de tes OOM pour les éviter, soit en augmentant la mémoire si c'est justifier, soit en adaptant tes algos pour être moins gourmands.

2) Si tu as des OOM et qu'il font "tomber" ton tomcat, surveiller les symptomes et non la cause. Même 10 secondes après le OOM tu peux avoir 50% de mémoire libérér car suite au OOM un thread / une requête est terminée / morte et aura libéré ses ressources.


Concernant le test de la mémoire disponible, utilise les MxBean plutot que runtime, tu y aura une vue plus détaillées.

http://javasearch.developpez.com/j2s...oryMXBean.html

enfin: totalmemory, c'est la mémoire occupée par la JVM, il te faut comparer à freememory pour savoir combien est réellement occupé par des objets.

[chouji77]

En fait, j'obtiens le OOM quand j'ai un grand nombre d'utilisateur sur l'application. J'ai augmenté au max la mémoire alloué pour Tomcat mais des OOM surgissent parfois (mais moins).
-> Je vais regarder ce que je peux optimiser dans le code.

Et je ne connaissais pas MxBean , merci de l'info.

Je mets la discussion en Résolu pour ne pas polluer le forum.
Je vais chercher de mon coté.

Merci #tchize_ pour ces détails, ça m'aide énormément. J'ai une meilleure vision sur le sujet maintenant.

[tchize_]

si par un grand nombre tu entends, par exemple, que ça a tendance à declencher un OOM quand tu serts 200 utilisateurs simultanément, tu peux aussi regarder à réduire le nombre de threads servant les requêtes tomcat. Moins de thread = moins de demandes simultanées de mémoire = moins de risques de OOM, mais aussi un risque de réactivité plus faible (mais pas toujours).