VisualVM "non pris en charge pour cette machine virtuelle" sur toutes les applications locales?
J'ai déjà passé beaucoup de temps à charger et à tester mon application, il me faut maintenant la profiler. Mais malheureusement, le VisualVM dit toujours "non supporté pour cette JVM" sur mes applications locales?
Les applications ont été démarrées sur la même machine virtuelle avec VisualVM.
J'ai découvert que (du moins sous Windows), on peut facilement écrire de petits fichiers de commandes pour exécuter VisualVM en combinaison avec des machines JVM spécifiques, ce qui est important pour moi, car j'ai installé le JDK 32 bits en même temps que le JDK 64 bits (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 doit toujours fonctionner correctement (sur toutes les versions 64 bits de Windows). L'avantage est que je peux utiliser le fichier de commandes 32 bits lorsque je souhaite utiliser VisualVM en combinaison avec des applications Java qui s'exécutent sur la JVM 32 bits, et ainsi de suite pour 64 bits.
La commande "start" présente le seul avantage que le fichier de commandes lance l'application sans attendre la fin. La fenêtre d'invite de commande se ferme immédiatement. Ce n'est pas une fonctionnalité de VisualVM, mais de l'interpréteur de fichiers de commandes Windows.
VisualVM doit être exécuté avec la même machine virtuelle (au moins Java 6, avec la même taille 32 bits/64 bits) que le programme à profiler. (Vous devez également être le même utilisateur, mais ce message ne s'applique pas).
Je vérifierais trois fois s'il s'agissait de la même machine virtuelle que dans votre cas.
Dans mon cas, même avec la mise en correspondance des machines virtuelles (64 bits), le seul moyen de faire fonctionner les choses était d'envoyer l'argument -Dcom.Sun.management.jmxremote à la machine virtuelle à surveiller. Cela fonctionne également si vous rencontrez des problèmes pour vous connecter via Java Mission Control (JMC).
Selon la documentation de JMX , voici ce que l'argument fait:
La définition de cette propriété a enregistré les MBeans de la plate-forme Java VM et publié 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 exécution de Java VM sur le même ordinateur que le client JMX.
Cela devait être activé automatiquement, mais pour une raison quelconque, ce n'était pas sous Linux.
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 différence puisse confondre totalement le pauvre jvisualvm et ses programmeurs.
J'ai aussi rencontré ce problème. Mon cas est que sur Linux, j'ai démarré Tomcat avec Tomcat_user mais je lance jvisualvm avec root. Cela fonctionne après que je lance Tomcat avec l'utilisateur root.
Comme vous pouvez le constater, vous exécutez VisualVM sur une machine virtuelle Java 32 bits
Vous n'avez pas besoin de désinstaller la machine virtuelle Java 32 bits. Il suffit de dire à VisualVM d’utiliser la machine virtuelle Java 64 bits.
Si vous voulez le changer de façon permanente, vous pouvez éditer
dans visualvm_13\etc\visualvm.conf et spécifiez le chemin de jvm ici
Un problème que je viens de découvrir, grâce au conseil de @ user3356656, est que si vous démarrez le programme alors que votre ordinateur utilise une adresse IP, puis que vous essayez de vous connecter alors qu'il se trouve sur une adresse IP différente, tout cela échouera.
Je peux reproduire le comportement suivant .J'ai une application Java avec un élément de menu contextuel pour ouvrir jvisualvm . J'exécute cette application Java en tant qu'installation autonome à partir d'un fichier bat . Cela signifie que je modifie% path% et d’autres variables d’environnement nécessaires telles que JDK en conséquence pour former mon environnement La BAT qui démarre l'application est marquée en cours d'exécution comme non admin. Environnement pointe vers un JDK 64 bits. Puis je lance une autre application Java en tant qu’administrateur. VM vit de la même source JDK 64 bits . Puis je lance jvisualvm à partir de la première application avec le clic droit, c'est-à-dire non administrateur. Je peux voir l’application dans jvisualvm ‘Liste des applications’ mais cliquer sur ‘Propriétés système’ donne une erreur. Le message est «Non pris en charge pour cette machine virtuelle»… .. Les arguments de la machine virtuelle sont exposés.
La solution est comme dans certains commentaires précédents: Commençant mon clic droit jvisualvm-starter en tant qu’administrateur, je peux voir aussi les "propriétés du système". Certes, si les JDK étaient en 32 bits et les autres 64 bits, cela ne fonctionnerait pas. été là.
Je pensais que cette notion devait être ajoutée ici à cause de cette petite secousse à moitié travaillante.
Mon problème était optimisations JVM - -XX:+PerfDisableSharedMem drapeau cassera VisualGC. Ceci est évident si jps ne montrera pas votre application dans la liste.
Le problème étant que visualvm détecte mon installation Tomcat locale sous Windows 7. Je pouvais me connecter manuellement, mais des éléments tels que les instantanés de mémoire et le plug-in visualgc n'étaient pas activés. J'ai confirmé que j'utilisais la même version de JVM, les mêmes autorisations de fichiers temporaires, etc. Cela n'a pas fonctionné. Ensuite, j’ai trouvé que le fait de démarrer visualvm d’abord, puis Tomcat, résolvait le problème.
J'ai changé le nom de mon utilisateur Windows et mis tout en minuscule, redémarré mon PC et tout fonctionne maintenant.
Moi aussi j'ai le même problème pour Tomcat local, je cherche des solutions pour stackoverflow. Après un débogage sérieux, j'ai découvert que VisualGC n'avait pas la permission d'obtenir des informations GC à partir du fichier tool.jar.
par des liens
http://docs.Oracle.com/javase/7/docs/technotes/tools/share/jstatd.html#SECURITYhttps://stackoverflow.com/a/42107355/3876619
Je suit les étapes pour résoudre le problème
1) Créer un fichier de permission
vim /tmp/tools.policy
Ajouter
grant codebase "file:${Java.home}/../lib/tools.jar" {
permission Java.security.AllPermission;
};
sauvegarde le
2) Ajoutez maintenant /tmp/tools.policy aux paramètres de démarrage de la machine virtuelle Java
-Djava.security.policy=/tmp/tools.policy
3) Lancer jvisualVm avec Sudo
Pour moi, la raison est que j'ai exécuté le "jstatd" avec un utilisateur différent avec le processus JVM. J'ai un utilisateur spécial dans le Linux pour démarrer le thread JVM (il s'agit d'un Tomcat), mais je lance le processus jstatd avec root. Si vous utilisez root pour exécuter jps, vous ne pouvez voir aucune information sur les threads JVM appartenant à d'autres utilisateurs. C’est là le problème . J’ai tué le processus "jstatd" démarré par root, su au propriétaire du processus JVM, puis relancé le processus "jstatd" et tout se passait bien maintenant.