Comment surveiller l'utilisation de la mémoire de Java ?

Question

Nous avons une application j2ee fonctionnant sur Jboss et nous voulons surveiller son utilisation de la mémoire. Actuellement, nous utilisons le code suivant

    System.gc();
    Runtime rt = Runtime.getRuntime();
    long usedMB = (rt.totalMemory() - rt.freeMemory()) / 1024 / 1024;
    logger.information(this, "memory usage" + usedMB);

Ce code fonctionne bien. Cela signifie qu'il montre une courbe de mémoire qui correspond à la réalité. Lorsque nous créons un gros fichier xml à partir d'une base de données, la courbe monte, puis elle descend une fois l'extraction terminée.

Un consultant nous a dit qu'appeler gc() explicitement est une erreur, "laissez le jvm décider quand lancer gc". En gros, ses arguments étaient les mêmes que discuté ici . Mais je ne comprends toujours pas :

• comment puis-je avoir une courbe d'utilisation de la mémoire ?
• qu'est-ce qui ne va pas avec le gc() explicite ? Je ne me soucie pas des petits problèmes de performance qui peuvent survenir avec la méthode gc() explicite et que j'estimerais à 1-3%. Ce dont j'ai besoin, c'est d'un moniteur de mémoire et de threads qui m'aide à analyser notre système sur le site du client.

Answer 1

Si vous voulez vraiment regarder ce qui se passe dans la mémoire de la VM, vous devriez utiliser un bon outil comme VisualVM . C'est un logiciel libre et c'est un excellent moyen de voir ce qui se passe.

Rien n'est vraiment "mauvais" avec explicite gc() appels. Toutefois, n'oubliez pas que lorsque vous appelez gc() vous "suggérez" que le ramasseur de déchets fonctionne. Il n'y a aucune garantie qu'il s'exécutera au moment exact où vous exécutez cette commande.

Answer 2

Il existe des outils qui vous permettent de surveiller l'utilisation de la mémoire de la VM. Le site La VM peut exposer les statistiques de la mémoire en utilisant JMX . Vous pouvez également imprimer les statistiques GC pour voir comment la mémoire se comporte dans le temps.

L'invocation de System.gc() peut nuire aux performances de la GC car les objets seront déplacés prématurément de la nouvelle à l'ancienne génération, et les références faibles seront effacées prématurément. Cela peut entraîner une diminution de l'efficacité de la mémoire, des temps de GC plus longs et une diminution des hits de cache (pour les caches qui utilisent des références faibles). Je suis d'accord avec votre consultant : System.gc() est mauvais. J'irais même jusqu'à le désactiver en utilisant le commutateur de ligne de commande.

Answer 3

Vous pouvez jeter un coup d'œil à moniteur de scène . Il s'agit d'un moniteur de performance d'applications java (web) open source. Il capture les métriques du temps de réponse, les métriques de la JVM, les détails de la requête (y compris une pile d'appels capturée par le profileur de requête) et plus encore. Les frais généraux sont très faibles.

En option, vous pouvez utiliser l'excellente base de données chronologique Graphite pour stocker un long historique de points de données que vous pouvez consulter à l'aide de tableaux de bord sophistiqués.

Ejemplo:

Jetez un coup d'œil à la site web du projet pour voir les captures d'écran, les descriptions des fonctionnalités et la documentation.

Note : Je suis le développeur de stagemonitor.

Answer 4

Je dirais que le consultant a raison en théorie, et que vous avez raison en pratique. Comme le On dit que :

En théorie, la théorie et la pratique sont identiques. En pratique, elles ne le sont pas.

La spécification Java indique que System.gc suggère d'appeler le garbage collection. En pratique, il crée simplement un thread et s'exécute immédiatement sur la JVM de Sun.

Bien qu'en théorie, vous puissiez perturber une implémentation finement réglée de la collecte des déchets par la JVM, à moins que vous n'écriviez du code générique destiné à être déployé sur n'importe quelle JVM, ne vous en préoccupez pas. Si cela fonctionne pour vous, faites-le.

Answer 5

Avez-vous essayé JMX ?

http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html

_{(source : <a href="http://java.sun.com/developer/technicalArticles/J2SE/jconsole/HeapMemory.jpg" rel="nofollow noreferrer">soleil.com </a>)}