Aide en ligne du monitoring JavaMelody
Le monitoring JavaMelody est un outil de mesure et de statistiques sur le fonctionnement réel d'une application selon l'usage qui en est fait par les utilisateurs.
Le monitoring est en grande partie basé sur des statistiques de requêtes et sur des courbes d'évolution. Il permet ainsi d'améliorer les applications en recette et en production et d'aider à :
factualiser les temps de réponse moyens et les nombres d'exécutions
prendre des décisions quand les tendances sont mauvaises
optimiser sur la base des temps de réponse les plus pénalisants
trouver les causes à l'origine des temps de réponse
vérifier l'amélioration réelle après des optimisations
Le rapport html de JavaMelody est optimisé pour Firefox, Chrome ou MSIE9 (MSIE7 non recommandé).
Projet JavaMelody
Home page
Downloads
Release notes
Documentations
Java SE documentations
Java SE Platform at a Glance
Troubleshooting Guide for Java SE 8
Monitoring and Management for Java SE 8
Java SE 6 Performance
Synthèse
Dans la page du monitoring, la synthèse présente des courbes d'évolution sur différentes valeurs de mesures.
Ces mesures sont effectuées à un instant t, par exemple toutes les minutes. Chaque courbe suit l'évolution d'une valeur de mesure sur la période plus ou moins large choisie par l'intermédiaire des liens
au-dessus de la synthèse : le jour, la semaine, le mois, l'année ou une période personnalisée. Dans chaque courbe sont suivies et indiquées en chiffres la valeur moyenne en vert et le
maximum en bleu. Les unités dans les courbes sont choisies automatiquement selon les valeurs : "m" pour millièmes (1 / 1000), "k" pour kilo/milliers, "M" pour méga/millions, "G" pour giga/milliards et "u" pour
micro (1 / 1000000). Les courbes sont persistées : un redémarrage du serveur d'application n'a pas d'influence sur elles hormis un trou dans les mesures.
Chaque courbe peut être affichée en grand et redimensionnée en cliquant sur celle-ci dans la synthèse.
Les courbes présentées sont :
la mémoire java utilisée, entre 0 et le maximum paramétré par Xmx dans la configuration du serveur
le pourcentage cpu utilisé par le processus java, entre 0 et 100 même s'il y a plusieurs coeurs ou plusieurs processeurs
le nombre de sessions http (ou nombre d'utilisateurs connectés)
le nombre de threads actifs (ou nombre de requêtes http en cours)
le nombre de connexions jdbc actives (ou nombre de requêtes sql en cours)
le nombre de connexions jdbc utilisées (ou nombre de transactions sql ouvertes); dans le cas où il n'y a pas de datasource, c'est en fait le nombre de connexions jdbc ouvertes dans le pool de
connexions
pour chacun des compteurs de requêtes (http, sql et éventuellement ejb, spring, guice, interfaces, actions jsf, actions struts, pages jsp) :
le nombre de hits par minute (ou nombre d'exécutions de requêtes par minute)
le temps moyen en millisecondes
le pourcentage d'erreurs systèmes (ces valeurs pour un compteur représente une moyenne pour la dernière période de mesure)
et aussi dans 'Autres courbes', des données qui sont globales pour la JVM ou pour l'OS :
si Tomcat ou JBoss, le nombre de threads actifs dans tout le serveur, le nombre d'octets reçus par minute et le nombre d'octets envoyés par minute par le serveur (le nombre d'octets reçus est
souvent 0 pour la plupart des webapps)
le pourcentage cpu du ramasse-miettes pour la JVM
le nombre de threads pour la JVM
le nombre de classes chargées pour la JVM
la mémoire utilisée hors tas pour la JVM
la mémoire physique utilisée pour l'OS
l'espace swap utilisé pour l'OS
l'age moyen des sessions http actuellement valides en minutes
si linux : la charge système et le nombre de fichiers ouverts pour l'OS
les transactions par minute (plus précisément, le nombre de connexions jdbc ouvertes par minute)
Les heures dans les graphiques pour le jour dépendent de l'heure du serveur et du fuseau horaire du serveur (timezone, défini par l'OS ou spécifiquement pour le serveur d'application).
Le lien ' Actualiser' permet de rafraîchir la page et les courbes. Le lien ' PDF' affiche tout le rapport en format PDF pour Adobe Reader.
Si un serveur de collecte est utilisé pour afficher le monitoring de plusieurs serveurs en ferme ou en cluster, la courbe de mémoire est la somme des mémoires sur les différents serveurs, mais le
pourcentage cpu est celui entre 0 et 100 pour tous les serveurs, et le nombre de sessions http est la somme des sessions sur les différents serveurs, de même que pour le nombre de threads actifs, le
nombre de connexions jdbc actives ou utilisées, et les hits par minute ou le temps moyen en millisecondes.
Courbe mémoire : cas d'utilisation d'une application utilisée par intermittence (jour/nuit par exemple)
La courbe de la mémoire augmente rapidement quand l'application est utilisée, et elle augmente doucement mais augmente tout de même quand l'application n'est pas utilisée. Une courbe avec des pentes,
comme dans l'exemple ci-dessus, est donc classique même si l'application n'est pas utilisée.
Dans tous les cas et selon la nécessité, la mémoire est finalement libérée d'un coup par le ramasse-miette (GC majeur) et revient à un niveau bas, avant de remonter plus ou moins vite. Si la résolution
paramétrée est suffisamment fine, la courbe montre également les GC mineurs en petites dents de scie entre les GC majeurs. Ces GC mineurs libèrent également la mémoire mais en moins grande quantité
que les GC majeurs. Il est possible de forcer un GC majeur par l'action ' Exécuter le ramasse-miette' dans la partie ' Informations systèmes' du rapport.
Courbe mémoire : cas d'utilisation d'une saturation mémoire
Si la courbe mémoire augmente jusqu'au maximum et si l'application ne peut en libérer avec le ramasse-miette, le serveur provoque éventuellement des erreurs "OutOfMemoryError: Java heap space" pour
interrompre le traitement et libérer si possible la mémoire.
Tant que la mémoire est insuffisante, le cpu reste à 100% car le ramasse-miette s'exécute en permanence. Cela peut provoquer de très fortes lenteurs et un quasi-blocage du serveur d'application.
Les solutions peuvent être d'augmenter la mémoire java maximum (paramètre Xmx au lancement du serveur, 64 Mo par défaut), et éventuellement la mémoire physique du serveur, ou bien d'optimiser si
possible la consommation mémoire de l'application.
Mémoire Perm Gen: cas d'utilisation d'une saturation perm gen
Si la valeur de la mémoire perm gen augmente jusqu'au maximum et si l'application ne peut en libérer, le serveur provoque éventuellement des erreurs "OutOfMemoryErrors: PermGen space" pour
interrompre le traitement. Cela peut bloquer toutes les fonctionnalités dans l'application.
Les solutions peuvent être d'augmenter la mémoire PermGen maximum (paramètre XX:MaxPermSize au lancement du serveur), et éventuellement la mémoire physique du serveur, ou bien d'optimiser si
possible le nombre de classes chargées par l'application.
Courbes de threads actifs et connexions jdbc actives : cas d'utilisation d'un plateau (requêtes longues)
Aide en ligne du monitoring JavaMelody
http://localhost:8090/test/monitoring?resource=help/help_fr.html
1 sur 3 12/02/2015 13:22