Вопросы Теги

Что вызывает PermGen OutOfMemoryError на JBoss?

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

Вы не можете только сказать "добавление большего количества точек отказа", не принимая во внимание вероятность того отказа. Тем более, что эти менее вероятные точки отказа должны конкретно на месте ниспровергать более вероятный катастрофический отказ жесткого диска. Как Вы выразились, Вы в основном создали Пари Паскаля - как ошибка.

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

, С другой стороны, хорошие фактические аппаратные средства RAID довольно надежен, и он имеет аппаратные средства, чтобы сделать его вещь без (несмотря на?) операционная система. Но они становятся дорогими, потому что реальные аппаратные средства обычно имеют резервные аккумуляторы и полный массив XOR'ing для вычисления контрольных сумм, и т.д. Еще более дорогих, если они сделали использование SCSI.

Сводка: Если Вы выполняете основанные на материнской плате системы RAID, то не, это не стоит проблемы.

8
задан 5 May 2009 в 11:27
3 ответа

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

  • Объекты упомянутых классов все еще существуют на "куче", объекты всегда ссылаются на свой класс, или
  • На загрузчик класса ссылаются где-нибудь по любой причине, загрузчики класса ссылаются на свои классы для не загрузки их дважды

Нет никакого всеобъемлющего решения этой проблемы. Один полезный инструмент, чтобы помочь Вам найти первопричину является Памятью Eclipse Инструмент Анализатора, который можно обратиться к дампу "кучи" от JVM (можно включить дампы "кучи" на OOMs с-XX: + опция HeapDumpOnOutOfMemoryError). Возможно, начните искать java.lang. Объекты класса из Вашего веб-приложения для наблюдения, почему они поддерживаются. К сожалению, PermGen обычно не является частью дампа "кучи" JVM, таким образом, можно только попытаться найти артефакты корреляции в остальной части "кучи" (Объекты класса не хранятся в PermGen, если я не ошибаюсь, только фактический код байта, исправьте меня, если я неправ хотя).

HTH.

Править:
Dave Cheney предлагает в комментарии это java.lang. Объекты класса являются действительно частью PermGen, и не включенные в нормальный дамп "кучи" горячей точки. Если у Вас нет JVM, которая пишет эту информацию в дампе "кучи", Вам будет нужен другой подход. Можно все еще искать экземпляры объектов, но если Вы пропускаете загрузчики классов/класса (они оба, к сожалению, подразумевают друг друга), кажется, что необходимо искать другие знаки (объекты метаданных от JBoss, и т.д.).

5
ответ дан 2 December 2019 в 23:02
  • 1
    I' m вполне уверенный, что Объекты класса хранятся в PermGen (то есть, объекты, которые являются экземплярами Класса). Существует отдельная область на JVM Sun, названной Кэшем Кода, который является, где код, который был скомпилирован в машинный код, хранится. И PermGen и Кэш Кода являются частью Не памяти "кучи", что Вы видите инструменты использования как jconsole –  Dave Cheney 5 May 2009 в 15:02
  • 2
    @Dave Cheney: You' корректное ре. Пропущенные Объекты класса, всунутые PermGen, обычно являются причиной OP' s проблема. –  Eddie 5 May 2009 в 18:02
  • 3
    икра, в то время как я don' t думают, что содержание PermGen записано в дамп "кучи" (это использует JVM Sun, я don' t имеют много опыта с другими), формат дампа hprof, конечно, знает вещи как, сколько классов было загружено, сколько загрузчиков класса, и т.д. Вы видите это при открытии hprof в Анализаторе Памяти Eclipse). То, что, вероятно, не записано, является большими двоичными данными класса, которые составляют байт-код Java, что Вы видите в дампе "кучи", ' stub' из Экземпляра класса, сохраненного на PermGen. –  Dave Cheney 5 May 2009 в 18:05

Первопричиной являются ссылки на классы, которые были отброшены, протекая вне их classloader, препятствуя тому, чтобы JVM разгрузила те классы от Генерала перманента. Те флаги, которые Вы используете, могут заставить JVM настойчиво производить чистку классов, которые являются незагружаемыми, но она не решит базовую проблему.

Существует польза, abeit сложное объяснение здесь

2
ответ дан 2 December 2019 в 23:02

Причиной ошибки PermGen OutOfMemory является приложение, повторно развертывается. Первопричиной являются пропущенные Объекты класса в PermGen от повторно развертывания.

Конечно, обходное решение должно перезапустить JVM после того, как определенное число повторно развернется.

Это - очень трудная проблема для общего решения, хотя с некоторыми выслеживающими Вас может часто делать большие улучшения. Вот то, где Вы запускаете: Когда Ваше веб-приложение будет остановлено, удостоверьтесь что:

  • останавливаются все Потоки, которые Вы запустили,
  • закрываются все ThreadPools, которые Вы запустили,
  • выпущены все статические ссылки, которые можно выпустить,

Это некоторые вещи, которые могут заставить Объект класса быть захваченным в PermGen.

Кроме того, обратите внимание, что не весь JVMs (или все версии JVMs) будут Объекты класса GC в PermGen. При выполнении JVM или версии JVM, которая не будет Объекты класса GC в PermGen, то единственный выбор состоит в том, чтобы перезапустить JVM после того, как определенное число повторно развертывается. Это, вероятно, не относится к Вам, учитывая опции JVM, которые Вы упоминаете.

1
ответ дан 2 December 2019 в 23:02

Теги

Похожие вопросы