Glassfish DAS OutOfMemory с общим использованием кучи ниже максимального размера кучи

Я запускаю большое корпоративное приложение в конфигурации кластера Glassfish V2.1 с 6 экземплярами (SLES 10 SP4, 64-разрядная машина Suse Linux с 19 ГБ ОЗУ), а в файле server.log машины DAS отображается ошибка java.lang.OutOfMemoryError: Ошибки пространства кучи Java». Отчет об использовании кучи из jvm.log DAS показывает:

Heap
 PSYoungGen      total 103488K, used 99840K [0x00002aab237c0000, 0x00002aab2a270000, 0x00002aab4e260000)
  eden space 99840K, 100% used [0x00002aab237c0000,0x00002aab29940000,0x00002aab29940000)
  from space 3648K, 0% used [0x00002aab29940000,0x00002aab29940000,0x00002aab29cd0000)
  to   space 4672K, 0% used [0x00002aab29de0000,0x00002aab29de0000,0x00002aab2a270000)
 PSOldGen        total 1398144K, used 1398143K [0x00002aaace260000, 0x00002aab237c0000, 0x00002aab237c0000)
  object space 1398144K, 99% used [0x00002aaace260000,0x00002aab237bfe70,0x00002aab237c0000)
 PSPermGen       total 107200K, used 106931K [0x00002aaaae260000, 0x00002aaab4b10000, 0x00002aaace260000)
  object space 107200K, 99% used [0x00002aaaae260000,0x00002aaab4accd98,0x00002aaab4b10000)

Из приведенного выше мы получаем общий объем кучи 1,6 Гб (103488 + 1398144 + 107200 = 1608832 ~ 1,6 Гб), хотя максимально допустимый объем кучи установлен равным 2 Гб (-XX:MaxPermSize=512m -Xmx2048m). Тогда мой вопрос: почему JVM не увеличивает размер кучи перед выводом ошибок OOM? Как мы можем интерпретировать приведенный выше отчет о куче? Я запустил инструмент MAT для двоичного файла кучи и получил 2 подозреваемых в утечке:

Problem suspect #1

One instance of "com.sun.jmx.mbeanserver.JmxMBeanServer" loaded by "<system class loader>" occupies 522,351,680 (34.12%) bytes. The instance is referenced by org.jvnet.glassfish.comms.admin.management.extensions.config.OverloadProtectionServiceConfigImpl @ 0x2aaacfe74ed0 , loaded by "com.sun.appserv.server.util.ASURLClassLoader @ 0x2aaace7fc630". The memory is accumulated in one instance of "java.util.HashMap$Entry[]" loaded by "<system class loader>".

Keywords
java.util.HashMap$Entry[]
com.sun.appserv.server.util.ASURLClassLoader @ 0x2aaace7fc630
com.sun.jmx.mbeanserver.JmxMBeanServer

Problem suspect #2

140,421 instances of "net.jxta.impl.endpoint.tcp.TcpMessenger", loaded by "com.sun.appserv.server.util.ASURLClassLoader @ 0x2aaace7fc630" occupy 735,809,464 (48.07%) bytes. These instances are referenced from one instance of "java.util.TimerTask[]", loaded by "<system class loader>"

Keywords
java.util.TimerTask[]
com.sun.appserv.server.util.ASURLClassLoader @ 0x2aaace7fc630
net.jxta.impl.endpoint.tcp.TcpMessenger

К сожалению, ошибка произошла несколько недель назад, и с тех пор машина была перезагружена, поэтому я мог потерять некоторую контекстную информацию. Я ищу подсказки или объяснения и пытаюсь предотвратить эти ошибки. Заранее благодарю за любую помощь.

ваше здоровье

/Сэм


performance out-of-memory jvm glassfish heap
person Sam Carter    schedule 16.03.2012    source источник
comment
Где настоящая ошибка OOM? Это больше похоже на то, что у вас закончился permgen, чем heap mem.   -  person Preston    schedule 17.03.2012

Ответы (1)


arrow_upward
0
arrow_downward

Тогда мой вопрос: почему JVM не увеличивает размер кучи перед выводом ошибок OOM?

С заданными вами параметрами JVM (-Xmx2048m) максимальное пространство кучи будет равно 2 ГБ, это верно, но вы не установили параметр начального пространства кучи -Xms1024.
Этот параметр укажет JVM предоставить серверу изначально 1024 МБ пространства кучи вместо того, чтобы медленно увеличивать его по мере необходимости.

Это может помешать вам получить ошибки OOM, потому что иногда JVM не замечает некоторые изменения памяти из-за GC.

Взгляните на это, чтобы настроить сервер приложений. .

Что касается ваших MemLeaks:
трудно сказать, являются ли они настоящими утечками памяти или просто некоторыми серверными классами.
Чтобы проверить это, вы можете запустить дамп памяти и проанализировать его, например. Анализатор памяти

Надеюсь, это поможет, получайте удовольствие!

person SimonSez    schedule 16.03.2012
comment
Я принял к сведению, что этот параметр начального размера кучи (-Xms) обязательно должен быть установлен (ИМХО на максимальное значение размера кучи). Комментарий, который вы сделали: потому что иногда JVM не замечает некоторые изменения памяти из-за GC, но меня это беспокоит. У вас есть конкретная ссылка на ошибку, которую я мог бы изучить? Я также заметил, что параметры JVM, связанные с GC и кучей, были установлены и настроены для экземпляров кластера, но только частично в конфигурации сервера (DAS). Спасибо за ваш проницательный ответ. - person Sam Carter; 19.03.2012
comment
Вы правы, значение -Xms должно быть установлено на значение -Xmx. Извините, на данный момент у меня нет никаких ссылок (только система отслеживания ошибок о том, что GC не выполняется после многократного повторного развертывания), но я могу порекомендовать это и эта статья о настройке сборки мусора. Они помогли мне решить эту проблему в моей среде! Ваше здоровье! - person SimonSez; 19.03.2012