it-swarm.com.ru

Снятие ниток на производстве

Я анализирую различия между подходами для получения дампов потоков. Ниже приведены пара из них, которые я изучаю

  1. Определение bean-компонента jmx, который запускает jstack через Runtime.exec () при нажатии на объявленную операцию bean-компонента.

  2. Поток демона, выполняющий «ManagementFactory.getThreadMXBean (). DumpAllThreads (true, true)» несколько раз после предварительно определенного интервала.

Сравнивая выходные данные дампа потока между этими двумя, я вижу следующие недостатки с подходом 2

  1. Дампы потоков, зарегистрированные с использованием подхода 2, не могут быть проанализированы с помощью анализаторов дампов с открытым исходным кодом, таких как TDA
  2. Выходной результат не включает собственный идентификатор потока, который может быть полезен при анализе проблем с высоким процессором (верно?)
  3. Еще?

Буду признателен за предложения/предложения по

  1. Есть ли недостатки в выполнении jstack через Runtime.exec () в производственном коде? какие-либо проблемы совместимости на различных операционных системах - Windows, Linux?

  2. Любой другой подход, чтобы взять дамп потока?

Спасибо.

Правка -  

Комбинированный подход 1 и 2, кажется, путь. У нас может быть выделенный поток, работающий в фоновом режиме и печатающий дампы потоков в файле журнала в формате, понятном анализаторам дампов потоков ........ Если требуется какая-либо дополнительная информация (например, скажем, возможно, собственный идентификатор потока), которая регистрируется только по выводу jstack мы делаем это вручную, как требуется.

20
Andy Dufresne

Ты можешь использовать 

jstack {pid} > stack-trace.log

работает как пользователь на поле, где запущен процесс.

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


Для анализа следов стека я периодически использую следующую выборку в выделенном потоке.

 Map<Thread, StackTraceElement[]> allStackTraces = Thread.getAllStackTraces();

Используя эту информацию, вы можете получить идентификатор потока, состояние выполнения и сравнить трассировки стека.

31
Peter Lawrey

С Java 8 в картинке, jcmd является предпочтительным подходом.

jcmd <PID> Thread.print

Ниже приведен фрагмент из документации Oracle :

В выпуске JDK 8 были представлены Java Mission Control, Java Flight Recorder и утилита jcmd для диагностики проблем с приложениями JVM и Java. Предлагается использовать последнюю утилиту, jcmd вместо предыдущей утилиты jstack, для расширенной диагностики и снижения производительности.

Однако доставка этого вместе с приложением может иметь последствия для лицензирования, в которых я не уверен.

7
Arnab Biswas

Если это * nix, я бы попробовал kill -3 <PID>, но тогда вам нужно знать идентификатор процесса и, возможно, у вас нет доступа к консоли?

4
Peter Liljenberg

Я бы посоветовал вам выполнить весь анализ кучи в промежуточной среде, если такая среда существует, а затем отразить требуемую настройку сервера приложений на производстве, если таковая имеется. Если вам нужны дампы для анализа использования памяти вашего приложения, то, возможно, вам стоит подумать о его профилировании для лучшего анализа.

Дампы кучи обычно генерируются в результате OutOfMemoryExceptions из-за утечек памяти и плохого управления памятью.

Посмотрите документацию к вашему Серверу приложений, большинство современных серверов имеют средства для создания дампов во время выполнения, помимо обычной причины, о которой я упоминал ранее, хотя результирующий дамп может зависеть от поставщика.

0
Waleed Madanat