2011-08-07 10 views
5

Dev sunucularımızdan biri her seferinde çökmeye devam ediyor ve raporlar çok benzer görünüyor. Hafıza eksikliğinden kaynaklandığını düşünüyoruz, ancak bunu doğrulamak istiyoruz. Bu sürece yardımcı olabilir misiniz? Aşağıda, ilgili bilgileri hs_err dosyasından bulabilirsiniz.JVM (64-bit 1.5.0._22), GCTaskThread'de çöküyor

Teşekkürler! Yon

Geçici bir çözüm
# 
# 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 
+0

Modern 1.6.x sürümüne yükseltme JVM açık (ve mantıklı) öneridir – skaffman

+0

Mümkün değil, bu sayede çok sayıda müşteriyle birlikte çalışan bir üründür. Başka fikirlerin var mı? – Yon

+1

JVM'niz çöküyor. Hata JVM'de. Eski bir JVM kullanıyorsunuz. Hata, daha yeni bir JVM'de sabittir. İstediğiniz cevap olmayabilir, ancak sonuç kaçınılmazdır. – skaffman

cevap

1

Bellek eksikliği, JVM'nin çökmesine neden olmamalıdır. Bunu yaparsa, bu bir JVM hatasıdır ve bir JVM hatası için tek gerçek düzeltme yükseltmektir.

  • kodunuzu veya bazı üçüncü taraf kütüphane şey için yerel kod kütüphaneleri kullanılarak, ve bu kod,

    arabası: Ben bu nerede düşünebilirsiniz

    sadece olasılıklar "senin hatan" dir

  • JVM yükleme kurnazca bozulmuş

    veya

  • bu makinede kesintili donanım hatası var.


    sorunun ardından GC günlüğü ile uygulama bu teyit edebilir etkin çalışan, bellek yetersizliği olduğundan şüpheleniyorsanız

. Ya da yığın boyutlarını ve diğer ayarları ayarlayabilir ve düzeltmeyi umuyorsunuz. Bir noktada

sen artık eski (sonu life'd) JVM'lerle üzerinde kurulumlar için destek sağlayabilir müşterilerinize söylemek zorunda olacak. Eğer bu bir JVM hatasıysa (şüphelendiğimiz gibi) o zaman, müşterileriniz destek için Oracle'a BÜYÜK bir çek imzalamadıkça, bunun için bir çözüm bulma şansı çok azdır.

+0

Şubat 2012'de Java 6'ya taşınacağız. Yukarıdaki raporda, eden boşluğun% 100, PermGen'in% 99 ve hatanın GCThread'de olduğunu gösteriyor. Bununla gerçekten karşılaşacak olan bizler miyiz? – Yon

+0

@Yon - * "Gerçekten bununla karşılaşacak kişiler miyiz?" * Muhtemelen hayır. Ama en iyi düzeltme yükseltmektir. –

3

, siz ": PermSize = 256m XX: MaxPermSize = 256m XX" ile perma gen boyutunu artırabilir. Bu sorunu çözmez, ancak çökmeyi geciktirir.

Ya da eşzamanlı gc gibi diğer gc politikasını deneyebilirsiniz.