Случайные сбои Java VM в ConcurrentGCThread

Question

У нас есть проблемы с JVM, работающими с интернет-приложениями при изменении нагрузки. Эта проблема приходит и уходит. Однажды мы видим, как умирают три виртуальных машины, и после этого ничего не происходит ни на неделю, ни на две. Мы еще не нашли шаблон, не нашли ничего, чтобы воспроизвести или вызвать его. Также поиск в базе данных Sun не помог.

Мы попробовали предложенное временное решение (-XX: -CMSPermGenPrecleaningEnabled -XX: -CMSConcurrentMTEnabled) из http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6354939 не помогло. Кажется, это просто изменит нить, которая ее вызывает ... или по крайней мере заставит нас поверить в это.

Также обновление до 1.6.0_13 не помогло, и запрос на ошибку Sun никогда не возвращал ответ.

Так что мой вопрос: кто-нибудь видел это или имеет идею, что искать? Может ли это быть связано с библиотеками ОС?

Edited: ОС Linux, OpenSuse работает на процессорах AMD (Linux 2.6.18.8-0.1-с.в. # 3 SMP чт 15 марта 1:21:48 GMT 2007 x86_64 x86_64 x86_64 GNU/Linux)

# 
# An unexpected error has been detected by Java Runtime Environment: 
# 
# SIGSEGV (0xb) at pc=0x062c75f5, pid=6667, tid=1090374560 
# 
# Java VM: Java HotSpot(TM) Server VM (11.2-b01 mixed mode linux-x86) 
# Problematic frame: 
# V [libjvm.so+0x2c75f5] 
# 
# If you would like to submit a bug report, please visit: 
# http://java.sun.com/webapps/bugreport/crash.jsp 
# 

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

Current thread (0x081ddc00): ConcurrentGCThread [stack: 0x40f5c000,0x40fdd000] [id=6679] 

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000c 

Registers: 
EAX=0x00000000, EBX=0x00000008, ECX=0x0bf5e510, EDX=0x42d6dcb0 
ESP=0x40fdc150, EBP=0x40fdc168, ESI=0x40fdc200, EDI=0xa19e9640 
EIP=0x062c75f5, CR2=0x0000000c, EFLAGS=0x00210206 

Top of Stack: (sp=0x40fdc150) 
0x40fdc150: 40fdc200 71c70000 0815a748 0815a704 
0x40fdc160: a19e9640 40fdc200 40fdc198 062c74cb 
0x40fdc170: 40fdc200 a19e9640 0bf5e510 0bf5e510 
0x40fdc180: 080ea6f0 40fdc200 00000010 a19e9640 
0x40fdc190: ad38a000 40fdc200 40fdc1c8 0629efaa 
0x40fdc1a0: 40fdc200 a19e9640 00000100 00000100 
0x40fdc1b0: 0815ab00 40fdc200 40fdc2b8 40fdc200 
0x40fdc1c0: 080ea5f0 0815a638 40fdc2b8 062c2905 

Instructions: (pc=0x062c75f5) 
0x062c75e5: 53 83 ec 0c 8b 7d 0c 8b 75 08 8b 47 04 8d 58 08 
0x062c75f5: 8b 53 04 89 d1 c1 f9 02 85 d2 7e 6f b8 04 00 00 

Stack: [0x40f5c000,0x40fdd000], sp=0x40fdc150, free space=512k 
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 
V [libjvm.so+0x2c75f5] 
V [libjvm.so+0x2c74cb] 
V [libjvm.so+0x29efaa] 
V [libjvm.so+0x2c2905] 
V [libjvm.so+0x2bb461] 
V [libjvm.so+0x2c9ef5] 
V [libjvm.so+0x506929] 
C [libpthread.so.0+0x52ab] 

Answer 1

Там было несколько исправлений ошибок, связанных с GC аварий с момента 6u13 .. вот некоторые из них:

• 6897143 - стресс-тест падает во время HeapInspection с использованием ParallelGC.
• 6845368 - крупные объекты причина аварии или неожиданного исключения
• 6840775 - Несколько JVM аварии видели с 1.6.0_10 путем раннего доступа 1.6.0_14 - возможно связанным с GC
• 6806226 - Signed целочисленного переполнения в расширяемой коде массива приводит к сбою JVM

Предлагаю использовать хотя бы Java 6 Update 18 (u18).

Answer 2

У меня была очень похожая свалка JVM. Причиной было отсутствие пространства памяти/подкачки в зоне Solaris. той же программы в 64-битном режиме (т.е. с возможностью Java -d64), ошибка была более явной:

A fatal error has been detected by the Java Runtime Environment:

java.lang.OutOfMemoryError: requested 395856 bytes for Chunk::new. Out of swap space?

Internal Error (allocation.cpp:272), pid=10847, tid=32 Error: Chunk::new

JRE version: 6.0_23-b05 Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b09 mixed mode solaris-sparc compressed oops) If you would like to submit a bug report, please visit: http://java.sun.com/webapps/bugreport/crash.jsp