Profilage d'une application Java en cours d'exécution en ligne de commande
Je profile l'exécution d'applications Java souvent avec VisualVM mais il a besoin de X pour s'exécuter sur la machine
Je sais que je peux me connecter via le port de gestion, mais ce sera un profilage échantillonné hors ligne qui ne me suffit pas.
Je cherche donc une solution avec laquelle je peux profiler l'utilisation du PROCESSEUR des méthodes d'une application Java en cours d'exécution à partir de la ligne de commande. Il me suffit de collecter des données sur le serveur puis les données collectées peuvent être analysées sur un autre serveur machine.
mise à Jour:
Il semble que je doive être plus précis. Je veux profiler une application Java en cours d'exécution à partir de la ligne de commande, je ne veux pas l'arrêter et la relancer.
6 answers
L'application jvmtop est un outil pratique pour le profilage à partir de la ligne de commande. Pas besoin d'arrêter la machine virtuelle java. Utilisation:
jvmtop.sh --profile <PID>
Vous donnera une sortie comme celle-ci qui sera mise à jour pendant que l'application s'exécute:
Profiling PID 24015: org.apache.catalina.startup.Bootstrap
36.16% ( 57.57s) hudson.model.AbstractBuild.calcChangeSet()
30.36% ( 48.33s) hudson.scm.SubversionChangeLogParser.parse()
7.14% ( 11.37s) org.kohsuke.stapler.jelly.JellyClassTearOff.parseScript()
...
L'avantage est qu'il ne prend pas l'utilisation de l'instrumentation. Les classes de la jvm à profiler ne seront pas modifiées.
Si vous cherchez quelque chose de plus visuel, jetez un œil à jvm-mon qui est basé sur jvmtop
Pouvez-vous collecter 10 ou 20 échantillons de pile avecjstack ? Alors si Foo est une méthode, son utilisation globale dans le temps est la fraction des échantillons la contenant. Son utilisation du PROCESSEUR est la fraction de ces échantillons qui ne se terminent pas par des E/S ou un appel système. Son "temps de soi" est la fraction d'échantillons dans laquelle il est lui-même le terminus.
Je n'ai besoin de rien de joli. Soit je l'exécute sous l'EDI et les collecte de cette façon, soit j'utilise quelque chose comme jstack qui capture le pile d'une application en cours d'exécution.
C'est la technique random-pause.
On dirait que la façon" intégrée " de profiler une application java à partir de la ligne de commande est de la démarrer avec des paramètres de ligne de commande de profilage, comme ceci
$ java -Xrunhprof:cpu=samples,file=myprogram.hprof ...
Examinez ensuite le fichier "myprogram.hprof " avec un outil d'interface graphique (ou un outil de serveur Web comme jhat) ou outil de ligne de commande après la fin du processus (et le fichier est créé à ce moment-là).
Si vous utilisez l'astuce du signal" QUITTER", mentionné https://stackoverflow.com/a/2344436/32453 ensuite, vous pouvez générer un fichier à volonté sans quitter la JVM (il semble s'ajouter au fichier de sortie précédent). Ou attendez que le processus se termine et il générera le fichier.
Ce profileur (intégré) fait un échantillon rarement donc généralement faible ralentissement/impact global.
Nous avons utilisé hprof sur nos serveurs et c'est certainement mieux que sysouts au cas où vous ne pourriez pas exécuter une session VisualVM à part entière.
Les exemples d'utilisation de hprof sont nombreux:
Vous pouvez exécuter la plupart des profileurs commerciaux à distance afin qu'un agent soit exécuté sur le serveur, puis se connecte à cet agent via un client sur votre machine de développement. Mon profileur préféré absolu est JProfiler. C'est un achat assez raisonnable, et c'est très stable (ce qui n'est pas le cas de tous les profileurs commerciaux).
Http://www.ej-technologies.com/products/jprofiler/overview.html
D'autres profileurs commerciaux qui sont stables, mais pas mes préférés sont YourKit.
Ces petits fournisseurs font de bons outils. Ces outils vous fourniront des tonnes d'informations sur les timings des méthodes, l'utilisation de la mémoire, le GC, etc. Bien plus que jconsole.
Une façon de profiler une JVM "déjà démarrée" consiste à agréger plusieurs jstacks pris au fil du temps.
Vous pouvez par exemple les analyser et les afficher en tant que FlameGraph (voir les détails dans les différentes réponses pour ce lien, je ne les inclurai pas de manière redondante ici).