Сбой JVM (64-разрядная версия 1.5.0._22) в GCTaskThread - PullRequest
5 голосов
/ 07 августа 2011

Время от времени происходит сбой одного из наших серверов разработки, и отчеты выглядят очень похоже. Мы думаем, что это связано с нехваткой памяти, но мы хотим это проверить. Не могли бы вы, ребята, помочь в этом процессе? Ниже вы найдете соответствующую информацию из файла hs_err.

Спасибо! Йон

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0x00002b84b6dee37c, pid=4196, tid=1081399616
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.5.0_22-b03 mixed mode)
# Problematic frame:
# V  [libjvm.so+0x5b437c]
#

---------------  T H R E A D  ---------------

Current thread (0x000000005db44970):  GCTaskThread [id=4200]

siginfo:si_signo=11, si_errno=0, si_code=128, si_addr=0x0000000000000000


Heap
 PSYoungGen      total 291968K, used 291760K [0x00002aaada600000, 0x00002aaaec400000, 0x00002aaaec400000)
  eden space 291136K, 100% used [0x00002aaada600000,0x00002aaaec250000,0x00002aaaec250000)
  from space 832K, 75% used [0x00002aaaec250000,0x00002aaaec2ec288,0x00002aaaec320000)
  to   space 896K, 21% used [0x00002aaaec320000,0x00002aaaec350000,0x00002aaaec400000)
 PSOldGen        total 583680K, used 385757K [0x00002aaab6c00000, 0x00002aaada600000, 0x00002aaada600000)
  object space 583680K, 66% used [0x00002aaab6c00000,0x00002aaace4b7438,0x00002aaada600000)
 PSPermGen       total 116736K, used 116682K [0x00002aaaaac00000, 0x00002aaab1e00000, 0x00002aaab6c00000)
  object space 116736K, 99% used [0x00002aaaaac00000,0x00002aaab1df2b78,0x00002aaab1e00000)


---------------  S Y S T E M  ---------------

OS:CentOS release 5.3 (Final)

uname:Linux 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64
libc:glibc 2.5 NPTL 2.5 
rlimit: STACK 10240k, CORE 0k, NPROC 16384, NOFILE 99999, AS infinity
load average:22.73 19.62 19.08

CPU:total 4 em64t

Memory: 4k page, physical 2059636k(196532k free), swap 128512k(120972k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (1.5.0_22-b03) for linux-amd64, built on Oct  9 2009 01:32:14 by java_re with gcc 3.2.2 (SuSE Linux)

time: Fri Aug  5 03:57:27 2011
elapsed time: 27420 seconds

Ответы [ 2 ]

3 голосов
/ 13 августа 2011

В качестве обходного пути вы можете увеличить размер perm gen на «-XX: PermSize = 256m -XX: MaxPermSize = 256m».Это не решает проблему, но задержит сбой.

Или вы можете попробовать другую политику gc, например, одновременный gc.

1 голос
/ 13 августа 2011

Недостаток памяти не должен вызывать сбои JVM.Если это так, то это ошибка JVM, и единственное реальное исправление ошибки JVM - это обновление.

Единственные возможности, которые я могу придумать, где это «ваша ошибка»:

  • ваш код или какая-либо сторонняя библиотека для чего-то использует библиотеки собственного кода, и этот код содержит ошибки,

  • ваша установка JVM была слегка повреждена, или

  • у вас периодически возникает аппаратная ошибка на этом компьютере.


Если вы подозреваете, что проблема заключается в нехватке памяти,затем запуск приложения с включенной регистрацией GC может подтвердить этоИли вы можете просто настроить размеры кучи и другие параметры и надеяться, что они это исправят.


В какой-то момент вам придется сказать своим клиентам, что вы больше не можете предоставлять поддержку для установки на старых(конец жизни) JVM.Если это ошибка JVM (как мы подозреваем), то у нее мало шансов исправить ее ... если только вы / ваши клиенты не захотите подписать БОЛЬШУЮ проверку в Oracle для поддержки.

...