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

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

0 голосов
/ 16 марта 2012

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

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 = 512 м -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

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

ура

/ Sam

1 Ответ

0 голосов
/ 17 марта 2012

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

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

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

Посмотрите на этот , чтобы настроить сервер приложений.

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

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

...