VisualVM "non supporté pour cette JVM" sur toutes les applications locales ?

Question

J'ai déjà passé beaucoup de temps à charger et à tester mon application, maintenant je dois la profiler. Mais malheureusement, la VisualVM dit toujours "not supported for this JVM" sur mes applications locales ?

Les applications ont été lancées sur la même JVM avec VisualVM.

Answer 1

J'ai découvert que (au moins sous Windows) on peut facilement écrire de petits fichiers batch pour exécuter VisualVM en combinaison avec des JVM spécifiques, ce qui est important pour moi, puisque j'ai installé le JDK 32bit à côté du JDK 64bit (j'ai besoin des deux, donc c'est raisonnable pour moi). J'ai créé deux fichiers batch dans le dossier " S:\applications\visualvm\bin\ " :

run_32.bat :

@echo off
START "VisualVM 32" visualvm.exe --jdkhome "C:\Program Files (x86)\Java\jdk1.7.0_07"

run_64.bat :

@echo off
START "VisualVM 64" visualvm.exe --jdkhome "C:\Program Files\Java\jdk1.7.0_07"

Évidemment, tous les chemins peuvent différer sur votre système, mais l'idée générale devrait quand même fonctionner correctement (sur toutes les versions 64 bits de Windows). L'avantage est que je peux utiliser le fichier batch 32bit lorsque je veux utiliser VisualVM en combinaison avec des applications Java qui tournent sur la JVM 32bit, et ainsi de suite pour 64bit.

La commande "start" a le seul avantage que le fichier batch lance l'application sans attendre qu'elle se termine, de sorte que la fenêtre de l'invite de commande se ferme immédiatement. Ceci n'est pas une caractéristique de VisualVM, mais de l'interpréteur de fichiers batch de Windows.

Answer 2

Dans mon cas, même avec les JVM correspondantes (toutes deux en 64 bits), le seul moyen de faire fonctionner les choses était d'envoyer l'argument -Dcom.sun.management.jmxremote à la JVM à surveiller. Cela fonctionne également si vous avez des problèmes de connexion via Java Mission Control (JMC).

Selon La documentation de JMX c'est ce que fait l'argument :

La définition de cette propriété a permis d'enregistrer les MBeans de la plate-forme Java VM et de publier le connecteur RMI (Remote Method Invocation) via une interface privée pour permettre aux applications clientes JMX de surveiller une plate-forme Java locale, c'est-à-dire une Java VM exécutée sur la même machine que le client JMX.

Cela était censé être activé automatiquement, mais pour une raison quelconque, ce n'était pas le cas sur mon Linux.

Answer 3

VisualVM doit être exécuté avec la même JVM - au moins Java 6 avec la même taille 32-bit/64-bit - que le programme à profiler. (Vous devez également être le même utilisateur, mais alors ce message ne s'applique pas).

Je vérifierais trois fois qu'il s'agit exactement de la même JVM dans votre situation.

Answer 4

J'ai eu le même problème avec mon tomcat local, j'ai cherché des solutions sur stackoverflow. Après un débogage sérieux, j'ai compris que VisualGC n'avait pas les permissions pour obtenir les informations GC du fichier tool.jar.

par des liens

http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstatd.html#SECURITY https://stackoverflow.com/a/42107355/3876619

Je suis les étapes suivantes pour résoudre le problème

1) Créer un fichier d'autorisation

vim /tmp/tools.policy

Ajouter

grant codebase "file:${java.home}/../lib/tools.jar" {
   permission java.security.AllPermission;
};

le sauver

2) Maintenant ajoutez /tmp/tools.policy aux paramètres de démarrage de la JVM

-Djava.security.policy=/tmp/tools.policy

3) Exécuter jvisualVm avec sudo

Answer 5

Sous Linux : Assurez-vous que votre /etc/hosts référence correctement l'adresse IP effective de votre "nom d'hôte". Il semble qu'une divergence ici perturbe totalement le pauvre jvisualvm et ses programmeurs.