VisualVM "не поддерживается для этой JVM" во всех локальных приложениях?

Ответ 1

Я узнал, что (по крайней мере, под Windows) можно легко написать небольшие пакетные файлы для запуска VisualVM в сочетании с определенными JVM, что важно для меня, так как я установил 32-битный JDK вместе с 64-битным JDK (мне нужно оба, так что это разумно для меня). Я создал два пакетных файла в папке "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"

Очевидно, что все пути могут отличаться в вашей системе, но общая идея должна работать корректно (на всех 64-битных версиях Windows). Преимущество в том, что я могу использовать 32-битный пакетный файл, когда я хочу использовать VisualVM в сочетании с Java-приложениями, которые работают на 32-битной JVM и т.д. Для 64-битных.

Команда "start" имеет единственное преимущество, что пакетный файл запускает приложение, не дожидаясь его завершения, поэтому окно командной строки немедленно закрывается. Это не функция VisualVM, а интерпретатор пакетного файла Windows.

Ответ 2

VisualVM необходимо запускать с тем же JVM - по крайней мере, с Java 6 с тем же 32-битным/64-битным размером - в качестве профилируемой программы. (Вы также должны быть одним и тем же пользователем, но тогда это сообщение не применяется).

Я бы трижды проверил, что это была то же самое JVM в вашей ситуации.

Ответ 3

В моем случае даже с совпадением JVM (как с 64-битным), единственным способом получить работу является отправка аргумента -Dcom.sun.management.jmxremote в JVM для мониторинга. Это также работает, если у вас возникли проблемы с подключением через Java Mission Control (JMC).

Согласно документации JMX, это то, что делает аргумент:

Настройка этого свойства зарегистрировала платформу Java VM платформы MBeans и опубликовала соединитель удаленного вызова метода (RMI) через частный интерфейс, чтобы позволить клиентским приложениям JMX отслеживать локальную платформу Java, то есть виртуальную машину Java, работающую на том же компьютере, что и клиент JMX.

Это должно было быть включено автоматически, но по какой-то причине это не было на моем Linux.

Ответ 4

В Linux: Убедитесь, что ваш /etc/hosts правильно ссылается на эффективный IP-адрес вашего "имени хоста", Похоже, что несоответствие здесь полностью смущает бедных jvisualvm и его программистов.

Ответ 5

Я также встретил эту проблему. Мое дело в том, что на linux я начал tomcat с tomcat_user, но я запускаю jvisualvm с пользователем root. Он работает после запуска tomcat с пользователем root.

Ответ 6

Как вы можете видеть, вы запускаете VisualVM на 32-битной JVM

Вам не нужно unistall 32bit JVM. Просто скажите VisualVM использовать тур 64bit JVM.

Если вы хотите изменить его навсегда, вы можете редактировать

в visualvm_13\etc\visualvm.conf и укажите здесь путь jvm

Ответ 7

Проблема, которую я только что нашел, благодаря подсказке от пользователя @user3356656, заключается в том, что если вы запустите программу, пока ваш компьютер находится на одном IP-адресе, а затем попытайтесь подключиться, когда он находится на другом IP-адресе, он будет терпеть неудачу.

Ответ 8

У меня возникла проблема с обнаружением visualvm моей локальной установки tomcat в Windows 7. Я мог подключиться вручную, но тогда такие вещи, как моментальные снимки памяти и плагин visualgc, не были включены. Я подтвердил, что использовал одну и ту же версию JVM, временные файлы и т.д. Не работал. Затем я обнаружил, что сначала начал visualvm, а затем tomcat, решил проблему.

Ответ 9

Я могу воспроизвести следующее поведение. У меня есть java-приложение, которое можно щелкнуть правой кнопкой мыши, чтобы открыть jvisualvm. Я запускаю это приложение Java как автономную настройку из файла bat. Это означает, что я изменяю% path% и другие необходимые переменные среды, такие как JDK соответственно, чтобы сформировать мою среду. БАТ, который запускает приложение, помечен как не-админ. Окружающая среда указывает на 64-битный JDK. Затем я запускаю другое приложение java в качестве администратора. VM живет от одного и того же 64-битного JDK-источника. Затем я запускаю jvisualvm из первого приложения с помощью правого клика ie.as non-admin. Я вижу приложение в списке приложений "jvisualvm", но при нажатии "Свойства системы" выдает ошибку. Сообщение "Не поддерживается для этой JVM". Экспортируются аргументы JVM.

Решение похоже на некоторые другие предыдущие комментарии: Начиная свой правый клик jvisualvm-starter в качестве администратора, я вижу также "свойства системы". Конечно, если JDK будут 32-битными и другие 64-битные, это не сработает. были там.

Я думал, что это понятие должно быть добавлено здесь из-за этого небольшого полурабочего рывка.

Ответ 10

Я изменил имя на моего пользователя Windows и установил его в нижнем регистре, перезапустил мой компьютер, и теперь все работает.

Ответ 11

У меня тоже такая же проблема для локального tomcat, я ищу решения для stackoverflow. после некоторой серьезной отладки я понял, что у VisualGC нет разрешений на получение информации GC из файла tool.jar.

по ссылкам

http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstatd.html#SECURITY fooobar.com/questions/163590/...

Я выполнил следующие шаги для решения проблемы

1) Создайте файл разрешений

vim /tmp/tools.policy

Добавить

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

сохранить

2) Теперь добавьте /tmp/tools.policy к параметрам запуска JVM

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

3) Запустите jvisualVm с sudo

Ответ 12

Моя проблема заключалась в оптимизации JVM - флаг -XX:+PerfDisableSharedMem нарушит работу VisualGC. Это очевидно, если jps не покажет ваше приложение в списке.

Ответ 13

Для меня причина в том, что я запускал "jstatd" с другим пользователем с процессом JVM. У меня есть специальный пользователь в Linux, чтобы запустить поток JVM (это tomcat), но я запускаю процесс jstatd с помощью root. Если вы используете root для запуска jps, вы не видите никакой информации о потоках JVM, принадлежащих другим пользователям. В этом проблема. Я убил процесс "jstatd" , запущенный с помощью root, su для владельца процесса JVM и перезапустил процесс "jstatd" , и теперь все будет хорошо.