Почему VisualVM Profiler не профилирует мое приложение?

Question

Я создал простое 1-файловое Java-приложение, которое выполняет итерации по циклу, вызывает некоторые функции, выделяет часть памяти, добавляет некоторые числа и т. Д. Я запускаю это приложение с помощью Run As->Java Application в eclipse.

Запущенное приложение отображается в Java VisualVM под Local.

Я дважды щелкаю по этому приложению и перехожу на вкладку Profiler.

Настройки по умолчанию:

Start profiling from classes: my.main.package.**

Do not profile classes: java.*, javax.*, sun.*, sunw.*, com.sun.*

Я нажимаю CPU.Кнопки CPU и Memory серого цвета.Ничего не происходит.

Status говорит profiling inactive.

Когда мое приложение завершается, Status говорит application terminated.

Что я здесь не так делаю?Есть ли какие-то настройки, которые мне нужно настроить?Нужно ли устанавливать флаг виртуальной машины при запуске приложения?

Answer 1

У меня была такая же проблема после обновления Java 1.7.0_45.Мне пришлось удалить следующую папку:

C:\users\'username'\AppData\Local\Temp\hsperfdata_'username'

После этого все работает как шарм.

Answer 2

Я предполагаю, что проблема связана с приложением, запускаемым из Eclipse, это потому, что JVisualVM ожидает найти данные в каталоге java.io.tmpdir (обычно C:\Users\[your username]\AppData\Local\Temp\hsperfdata_[your username] в системе Windows).

Я предполагаю , а не в обычном месте, где его ожидают JPS, JVisualVM и т. Д. Eclipse помещает данные в свою временную папку?

Если это так, попробуйте вызвать JVisualVM, используя jvisualvm -J-Djava.io.tmpdir=[Eclipse's temp directory], чтобы явно указать ему, где находятся эти данные.

Если вы не можете найти папку hsperfdata_$USER, попробуйте просто запустить приложение вне Eclipse обычным способом командной строки Java.

Также обратите внимание, что произошла ошибка, влияющая на временную папку (чувствительность к регистру), появившуюся около 1.6.0_23, так что, возможно, вы выиграете от обновления до более новой сборки Java 6 (или 7)?

Answer 3

Микавели, Куба и Сомайя Кумбера предоставили отличные решения. Просто добавляю, что я сделал, чтобы все заработало.

Сначала я проверил местоположение C:\users\'username'\AppData\Local\Temp\hsperfdata_'username'

Не было файла с именем, идентифицирующим процесс моей программы, работающей в eclipse.

Я просто остановил программу и добавил следующий параметр в Конфигурации запуска программы ( Конфигурации запуска -> Аргументы -> Аргументы VM )

-Djava.io.tmpdir=C:\users\'username'\AppData\Local\Temp\hsperfdata_'username'

Я снова запустил программу. Все еще не мог профилировать это. Но теперь у меня есть файл, созданный для процесса в данном временном каталоге.

Затем простой перезапуск VisualVM добился цели.

Answer 4

У меня была та же проблема, но со следующими симптомами:

Я запустил Jetty с рабочим каталогом в C: \ Users \ t852124 \ AppData \ Local \ Temp

Jetty былсоздание каталога hsperfdata_, но не установка в нем идентификатора процесса

Поэтому, когда я запустил VisualVM, он не смог получить информацию о процессе Java.

Я решил эту проблему, запустив jetty с -Djava.io.tmpdir = C: / temp / java опция.

Теперь, когда я запустил Jetty, идентификатор процесса был создан в виде файла в каталоге hsperfdata_.Поэтому, когда я запустил VisualVM, он смог увидеть мой локальный процесс Java

Answer 5

Также обратите внимание, что если ваше приложение использует недавно выпущенную JVM, отличную от Oracle, вам может потребоваться загрузить «передовой» VisualVM с github .

Например, VisualVM в комплекте с JDK 1.8.0.111, похоже, не работает с IBM 1.8 JVM. Возможно, IBM JVM была просто выпущена после Oracle 1.8 JVM, поэтому включение необходимых изменений в то время было невозможно.

Answer 6

У меня была такая же проблема, и запуск VisualVM с повышенными привилегиями (права администратора) решил эту проблему.

Answer 7

В Linux с VisualVM 1.3.3 мне нужно удалить локальные настройки приложения в ~/.visualvm/1.3.3/, чтобы включить CPU Profiler и CPU Sampler.

Также обратите внимание, что / usr / bin / jvisualvm содержит жестко закодированный путь к OpenJDK(устанавливается с переменной jdkhome), которая, по-видимому, вызывает много проблем по сравнению с работой на Oracle JDK 1.7.