Получение отвалов в производстве

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

Определение jmx bean, которое запускает jstack через Runtime.exec() при нажатии объявленной операции bean.
Демон, выполняющий "ManagementFactory.getThreadMXBean(). dumpAllThreads (true, true)" повторно после предопределенного интервала.

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

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

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

Есть ли недостатки выполнения jstack через Runtime.exec() в производственном коде? любые проблемы совместимости с различными операционными системами - windows, linux?
Любой другой подход для создания дампов потоков?

Спасибо.

Изменить -

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

Ответ 1

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

jstack {pid} > stack-trace.log

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

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

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

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

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

Ответ 2

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

jcmd <PID> Thread.print

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

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

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

Ответ 3

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

Ответ 4

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

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

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