Сбор дампов потоков в продакшене

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

  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, мы делаем это вручную по мере необходимости.


java thread-dump runtime.exec
person Andy Dufresne    schedule 02.01.2013    source источник
comment
Это связано с приложением JEE?   -  person Waleed Madanat    schedule 02.01.2013

Ответы (4)


arrow_upward
33
arrow_downward

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

jstack {pid} > stack-trace.log

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

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

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

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

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

person Peter Lawrey    schedule 02.01.2013
comment
Первая точка выполнения jstack такая же, как и в подходе 1, о котором я упоминал выше? Интеграция и запуск через jmx помогает пользователю не беспокоиться об идентификаторе процесса. Также с подходом jmx мы можем запланировать повторное выполнение jstack через каждый указанный интервал. Что касается второго пункта о вызове Thread.getAllStackTraces(); это означало бы, что я бы вручную регистрировал дамп потока таким образом, чтобы он интерпретировался анализаторами дампа потока. В чем преимущество этого подхода по сравнению с первым, который вы упомянули? - person Andy Dufresne; 02.01.2013
comment
Я бы включил анализаторы в программу и регистрировал только интересующую вас информацию. В моем случае это происходит только тогда, когда у меня есть проблема, что обычно означает, что я хочу увидеть, какие другие журналы происходят в это время, например. в какое время это произошло, что было последним, что поток зарегистрировал, и какая ошибка возникла впоследствии. - person Peter Lawrey; 02.01.2013

arrow_upward
8
arrow_downward

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

jcmd <PID> Thread.print

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

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

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

person Arnab Biswas    schedule 14.12.2016
comment
Это хорошо знать. Могут ли они быть проанализированы анализаторами дампа потока с открытым исходным кодом, такими как TDA? Включают ли они собственный идентификатор потока? - person Andy Dufresne; 15.12.2016

arrow_upward
5
arrow_downward

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

person Peter Svensson    schedule 02.01.2013
comment
да. Доступ к консоли и получение идентификатора процесса являются проблемами подхода kill. Подходы, о которых я упоминал выше, лишены этих недостатков. - person Andy Dufresne; 02.01.2013

arrow_upward
1
arrow_downward

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

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

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

person Waleed Madanat    schedule 02.01.2013
comment
Я понимаю накладные расходы на получение дампа потока, но чтобы получить четкое представление о том, что происходит в производственной среде, нам нужна эта функция. Мы используем сервер приложений Glassfish, и в получении дампа потока в Glassfish нет ничего особенного. Вам нужно отправить сигнал об уничтожении jvm, у которого есть два недостатка, упомянутых в моем ответе @Peter Lljenbery. - person Andy Dufresne; 02.01.2013
comment
Понял, тогда я бы порекомендовал вам использовать специальную сборку с включенным дампом памяти (возможно, через конфигурацию) и оценить вещи для вашей оценки, а затем отключить ее, как только вы закончите. Таким образом, вам не придется беспокоиться о последствиях использования jstack или любого другого подобного подхода. На самом деле, в этом сценарии jstack подойдет. Вам также следует проверить эту ссылку. , это может немного помочь (прокрутите до раздела «Описание»). - person Waleed Madanat; 02.01.2013
comment
Итак, вы рекомендуете подход 2 из моего описания выше? Что вы думаете о недостатках, о которых я упоминал выше? Также вы думаете, что могут возникнуть проблемы с выполнением runtime.exec() в производственных средах? - person Andy Dufresne; 02.01.2013
comment
Напротив, я говорю, что jstack выполнит эту работу с учетом ваших обстоятельств, я просто предлагаю вам добавить в ваше приложение некоторые средства, с помощью которых вы можете запускать эти дампы по требованию, и иметь конфигурацию, чтобы полностью отключить эту функцию. также. Вы не хотите, чтобы он был доступен в производстве. - person Waleed Madanat; 02.01.2013