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崩潰

回答

相關問題