JVM（64位1.5.0._22）在GCTaskThread崩溃

我们的一台开发服务器不时崩溃，报告看起来非常相似。我们认为这是由于内存不足，但我们想验证这一点。你们能帮助这个过程吗？您可以在下面找到hs_err文件中的相关信息。JVM（64位1.5.0._22）在GCTaskThread崩溃

谢谢！勇

# 
# 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

来源

2011-08-07 Yon

升级到现代1.6.x JVM是显而易见的（也是合理的）建议 – skaffman

不可能，这是一个与众多客户部署的产品。任何其他想法？ – Yon

您的JVM崩溃。该错误在JVM中。您正在使用旧的JVM。该错误很可能在更新的JVM中得到修复。这可能不是你想要的答案，但结论是不可避免的。 – skaffman

缺少内存不应导致JVM崩溃。如果是这样，这是一个JVM错误，唯一真正解决JVM错误的方法是升级。

我能想到的地方，这是唯一的可能性“你的错”是：

您的代码或一些第三方库使用本机代码库的东西，而且代码是越野车，
您的JVM安装已被巧妙地损坏，或
你已经有了这台机器上的间歇性硬件故障。

如果您怀疑问题是缺乏内存，那么在运行的GC日志记录应用程序启用可以证实这一点。或者你可以调整堆大小和其他设置，并希望他们修复它。

在某些时候，你将要告诉你的客户，你可以不再为旧（结束续航最好）的JVM的安装支持。如果这是一个JVM错误（正如我们所怀疑的那样），那么几乎没有机会获得修复，除非您/您的客户愿意在Oracle上签名以获得支持。

来源

2011-08-13 06:25:56

我们将在2012年2月转向Java 6。上面的报告显示eden空间为100％，PermGen为99％，故障在GCThread。我们是否真的遇到过这种情况？ – Yon

@Yon - *“我们是否真的遇到过这种情况？”*可能不是。但最好的解决方法是升级。 –

作为变通，你可以通过 “：PermSize =256米-XX：MaxPermSize参数=256米-XX” 增加烫发根的大小。它不能解决问题，但它会延迟崩溃。

或者你可以尝试像gc一样的其他gc策略。

来源

2011-08-13 06:00:07

JVM（64位1.5.0._22）在GCTaskThread崩溃

回答

相关问题