JMC: различия между версиями
FireWolf (обсуждение | вклад) |
FireWolf (обсуждение | вклад) |
||
| (не показано 8 промежуточных версий этого же участника) | |||
| Строка 1: | Строка 1: | ||
== Источник == | |||
Видео: https://www.youtube.com/watch?v=wm2JNlaJJ5k | Видео: https://www.youtube.com/watch?v=wm2JNlaJJ5k | ||
GIT: https://github.com/aragozin/optaplanner-bench | |||
GIST: https://gist.github.com/aragozin/6ac622de6328a1b6ee58a1bf6f2e523d | GIST: https://gist.github.com/aragozin/6ac622de6328a1b6ee58a1bf6f2e523d | ||
| Строка 5: | Строка 8: | ||
JMC: https://download.oracle.com/otn-pub/java/jmc/7.1.2+04/a4634525489241b9a9e1aa73d9e118e6/jmc-7.1.2_windows-x64.zip | JMC: https://download.oracle.com/otn-pub/java/jmc/7.1.2+04/a4634525489241b9a9e1aa73d9e118e6/jmc-7.1.2_windows-x64.zip | ||
== Weblogic == | |||
Для подключения к weblogic нужно докинуть wlclient.jar, wljmxclient.jar в катоалог с jmc и настроить jmc.ini: | Для подключения к weblogic нужно докинуть wlclient.jar, wljmxclient.jar в катоалог с jmc и настроить jmc.ini: | ||
< | <syntaxhighlight lang="ini"> | ||
-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote | -Djmx.remote.protocol.provider.pkgs=weblogic.management.remote | ||
-Djava.naming.factory.initial=weblogic.jndi.WLInitialContextFactory | |||
-Xbootclasspath/a:wlclient.jar;wljmxclient.jar ### !!! Тут ; или : в зависимости от ОС | |||
</syntaxhighlight> | |||
== Локальное профилирование == | |||
Если не видим локальные процессы, то варианта два: 1. в папку hsperfdata_<UserName> нет доступа по записи или 2. запустили JMC с помощью jre. | |||
1 вариант решается доступами или удалением каталога. | |||
2 вариант проблемы решается прописыванием JDK в jmc.ini: | |||
<syntaxhighlight lang="ini"> | |||
-vm | |||
D:\Program Files\Zulu\zulu-8\bin\ | |||
</syntaxhighlight> | |||
== Применение == | |||
Применяем профилирование когда мы уверены, что наш код грузит CPU и ничего не ждет (нет ожидания IO). | |||
Для выявления какой же поток сжирает CPU делаем Start JMX Console и идем на вкладочку Threads, там ставим галочку CPU Profiling. | |||
По задаче (branch jmc_workbench): Просто посмотрев на запущенные треды ощущается проблема тут: org.optaplanner.examples.machinereassignment.domain.MrProcess.getUsage line: 75 | |||
- | Запускаем Fligth Recorder и идем в Exceptions - видим (JMC menu: "Window -> Show View -> Stack Trace"), что NoSuchElementException выбросили около 4_000_000 раз. Подтверждая увиденное выше. | ||
Это точка оптимизации. | |||
Идем на opto_step_0 | |||
Текущая версия на 11:10, 27 ноября 2020
Источник
Видео: https://www.youtube.com/watch?v=wm2JNlaJJ5k
GIT: https://github.com/aragozin/optaplanner-bench
GIST: https://gist.github.com/aragozin/6ac622de6328a1b6ee58a1bf6f2e523d
Weblogic
Для подключения к weblogic нужно докинуть wlclient.jar, wljmxclient.jar в катоалог с jmc и настроить jmc.ini:
-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote
-Djava.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
-Xbootclasspath/a:wlclient.jar;wljmxclient.jar ### !!! Тут ; или : в зависимости от ОС
Локальное профилирование
Если не видим локальные процессы, то варианта два: 1. в папку hsperfdata_<UserName> нет доступа по записи или 2. запустили JMC с помощью jre.
1 вариант решается доступами или удалением каталога.
2 вариант проблемы решается прописыванием JDK в jmc.ini:
-vm
D:\Program Files\Zulu\zulu-8\bin\
Применение
Применяем профилирование когда мы уверены, что наш код грузит CPU и ничего не ждет (нет ожидания IO).
Для выявления какой же поток сжирает CPU делаем Start JMX Console и идем на вкладочку Threads, там ставим галочку CPU Profiling.
По задаче (branch jmc_workbench): Просто посмотрев на запущенные треды ощущается проблема тут: org.optaplanner.examples.machinereassignment.domain.MrProcess.getUsage line: 75
Запускаем Fligth Recorder и идем в Exceptions - видим (JMC menu: "Window -> Show View -> Stack Trace"), что NoSuchElementException выбросили около 4_000_000 раз. Подтверждая увиденное выше.
Это точка оптимизации.
Идем на opto_step_0