Когда JVM падает (segfaults) во время сборки мусора, как я могу узнать, что собиралось? - PullRequest
Новая
       28

Когда JVM падает (segfaults) во время сборки мусора, как я могу узнать, что собиралось?

12 голосов
/ 11 ноября 2011

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

Так как сбой происходит во всех трех JVM, которые я пробовал (OpenJDK 6, Oracle 1.6.0_25 и 1.7.0) и с двумя GC (Parallel Collector и CMS), и это происходит в одной и той же области приложения, я Я подумал, что если бы я мог найти то, что собирал GC, я мог бы обнаружить некоторую особенность в моем коде, которая вызывает этот сбой.

  • Существуют ли какие-либо методы кодирования, которые, как известно, являются проблематичными для GC?
  • Какие методы доступны для диагностики этой проблемы?
  • Могу ли я сделать какие-либо обоснованные предположения о том, где в моем приложении возникает эта проблема?
  • С какими параметрами (настройка ГХ) можно играть, чтобы сузить проблему?
  • Есть ли способ обнаружить (возможно) проблемные данные в дампе кучи?

Ответы [ 4 ]

8 голосов
/ 11 ноября 2011

Это произойдет, если у вас есть библиотека JNI, которая неправильно обрабатывает память.Проблема не показывает сразу.Однако, когда GC выполняется, он сканирует всю память, отключается по поврежденной ссылке и убивает JVM.то есть повреждение могло произойти в любое время с момента последнего полного сбора данных.

1 голос
/ 11 ноября 2011

  • ошибки сегмента имеют определенные коды ошибок в начале дампа http://en.wikipedia.org/wiki/Segmentation_fault

  • Вы можете использовать Thread.dumpStackTrace, чтобы увидеть, что происходит в этом приложении. Если выточно знать, где ваше приложение зависает или собирается заморозиться после определенного действия или события, вы можете CTRL + разбить окна или CTRL + \, чтобы получить дамп потока и посмотреть, что происходит.

  • Вместо смутного гадания вы можете закомментировать определенные разделы кода, чтобы узнать, какой цикл, объект, буфер или строка занимает слишком много времени

  • В зависимости от вашей ситуации вы можете рассмотреть некоторые конкретные инструменты.

0 голосов
/ 21 мая 2012

Мы также столкнулись с похожей проблемой. Там не было никакой картины, которую мы могли видеть, и это было довольно случайно, но происходило или на GC или на Full GC. Для нас это оказалось проблемой с модулями оперативной памяти. Мы определили это с помощью MemTest86 + на сервере Ubuntu.

0 голосов
/ 11 ноября 2011
  • Я предлагаю вам получить как дамп потока, так и дамп кучи. Вы можете сделать это либо из командной строки, либо использовать инструмент, подобный Visual VM
  • Я думаю, что дамп кучи моментальныйвыстрел из памяти JVM предоставит информацию о живых объектах и ​​их распределении.Если вы анализируете кучу с помощью Visual VM, она предоставляет подробный отчет обо всех объектах в куче
  • . Я бы посоветовал вам собрать коллекцию GC в вашем приложении, чтобы подробно и проанализировать их с помощью инструмента, подобного tagtraum
  • Если вы можете прикрепить JVM profiler , который может предоставить много информации, или если у вас есть общее представление о рабочем процессе, который вызывает проблему, тогда просто профилируйтев изоляции
...