Я уже потратил много времени на загрузку и тестирование своего приложения, теперь мне нужно его профилировать. Но, к несчастью, VisualVM всегда говорит "не поддерживается для этой JVM" в моих локальных приложениях?
Приложения были запущены на одной JVM с помощью VisualVM.
Я узнал, что (по крайней мере, под 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.
VisualVM необходимо запускать с тем же JVM - по крайней мере, с Java 6 с тем же 32-битным/64-битным размером - в качестве профилируемой программы. (Вы также должны быть одним и тем же пользователем, но тогда это сообщение не применяется).
Я бы трижды проверил, что это была то же самое JVM в вашей ситуации.
В моем случае даже с совпадением JVM (как с 64-битным), единственным способом получить работу является отправка аргумента -Dcom.sun.management.jmxremote в JVM для мониторинга. Это также работает, если у вас возникли проблемы с подключением через Java Mission Control (JMC).
Согласно документации JMX, это то, что делает аргумент:
Настройка этого свойства зарегистрировала платформу Java VM платформы MBeans и опубликовала соединитель удаленного вызова метода (RMI) через частный интерфейс, чтобы позволить клиентским приложениям JMX отслеживать локальную платформу Java, то есть виртуальную машину Java, работающую на том же компьютере, что и клиент JMX.
Это должно было быть включено автоматически, но по какой-то причине это не было на моем Linux.
В Linux: Убедитесь, что ваш /etc/hosts правильно ссылается на эффективный IP-адрес вашего "имени хоста", Похоже, что несоответствие здесь полностью смущает бедных jvisualvm и его программистов.
Я также встретил эту проблему. Мое дело в том, что на linux я начал tomcat с tomcat_user, но я запускаю jvisualvm с пользователем root. Он работает после запуска tomcat с пользователем root.
Как вы можете видеть, вы запускаете VisualVM на 32-битной JVM
Вам не нужно unistall 32bit JVM. Просто скажите VisualVM использовать тур 64bit JVM.
Если вы хотите изменить его навсегда, вы можете редактировать
в visualvm_13\etc\visualvm.conf и укажите здесь путь jvm
Проблема, которую я только что нашел, благодаря подсказке от пользователя @user3356656, заключается в том, что если вы запустите программу, пока ваш компьютер находится на одном IP-адресе, а затем попытайтесь подключиться, когда он находится на другом IP-адресе, он будет терпеть неудачу.
У меня возникла проблема с обнаружением visualvm моей локальной установки tomcat в Windows 7. Я мог подключиться вручную, но тогда такие вещи, как моментальные снимки памяти и плагин visualgc, не были включены. Я подтвердил, что использовал одну и ту же версию JVM, временные файлы и т.д. Не работал. Затем я обнаружил, что сначала начал visualvm, а затем tomcat, решил проблему.
Я могу воспроизвести следующее поведение. У меня есть 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-битные, это не сработает. были там.
Я думал, что это понятие должно быть добавлено здесь из-за этого небольшого полурабочего рывка.
Я изменил имя на моего пользователя Windows и установил его в нижнем регистре, перезапустил мой компьютер, и теперь все работает.
У меня тоже такая же проблема для локального 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
Моя проблема заключалась в оптимизации JVM - флаг -XX:+PerfDisableSharedMem нарушит работу VisualGC. Это очевидно, если jps не покажет ваше приложение в списке.
Для меня причина в том, что я запускал "jstatd" с другим пользователем с процессом JVM. У меня есть специальный пользователь в Linux, чтобы запустить поток JVM (это tomcat), но я запускаю процесс jstatd с помощью root. Если вы используете root для запуска jps, вы не видите никакой информации о потоках JVM, принадлежащих другим пользователям. В этом проблема. Я убил процесс "jstatd" , запущенный с помощью root, su для владельца процесса JVM и перезапустил процесс "jstatd" , и теперь все будет хорошо.