GCTaskThreadでJVM（64ビット1.5.0._22）がクラッシュする

Question

私たちのdevサーバの1つが毎回クラッシュし続け、レポートも非常に似ています。メモリ不足によるものだと考えていますが、これを検証したいと考えています。あなたはこのプロセスで助けてくれますか？ 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 

Answer 1

メモリが不足しているとJVMがクラッシュしません。そうであれば、それはJVMバグです.JVMバグの唯一の現実的な修正は、アップグレードすることです。

• あなたのコードや一部のサードパーティ製ライブラリが何かのためにネイティブコードライブラリを使用しており、そのコードは、

  バグがある：私はこれがどこにあるかを考えることができ

  唯一の可能性は「あなたのせいで」です

• あなたのJVMのインストールが微妙にあなたがそのマシン上の断続的なハードウェア障害を持っている、破損、または

• されています。

---

あなたは問題がメモリ不足であると思われる場合は、その後、GCログを使用してアプリケーションを有効に実行することは、これを確認することができます。あるいは、ヒープサイズやその他の設定を微調整し、修正することができます。いくつかの時点で

---

あなたは、もはや古い（エンド・オブ・life'd）のJVM上のインストールのサポートを提供することはできませんあなたの顧客に伝えるために持ってしようとしています。これがJVMのバグであれば（それが疑わしい）、あなた/あなたの顧客がOracleにBIGチェックをしてサポートを依頼しない限り、それを修正する機会はほとんどありません。

Answer 2

、あなたは "-XX：PermSizeを= 256メートル-XX：MaxPermSizeを= 256メートル" でパーマ世代のサイズを大きくすることができます。それは問題を解決するものではありませんが、クラッシュを遅らせるでしょう。

また、並行gcのような他のgcポリシーを試すこともできます。