java.lang.OutOfMemoryError: поискани 1958536 байта за Chunk::new. Няма място за размяна

Сблъскваме се с проблема по-долу в нашата производствена среда по непредсказуем начин, понякога сървърът спира след ден или понякога след седмица, по-долу е точният дъмп на грешката, по-долу са настройките за сървъра.

JDK: jdk1.6.0_21
Server: Tomcat 7.0.2
OS: Red Hat Enterprise Linux Server release 5.5

В catalina.sh е направена следната настройка:

JAVA_OPTS="-Xms1024M -Xmx1536M -XX:+HeapDumpOnOutOfMemoryError -XX:+AggressiveOpts 
-XX:-DisableExplicitGC  -XX:AdaptiveSizeThroughPutPolicy=0  
-XX:+UsePSAdaptiveSurvivorSizePolicy 
-XX:+UseAdaptiveGenerationSizePolicyAtMinorCollection  
-XX:+UseAdaptiveGenerationSizePolicyAtMajorCollection -XX:PermSize=768M 
-XX:MaxPermSize=768M    -XX:+PrintGCDetails -Xloggc:/tmp/gcLogs.txt"

export CATALINA_OPTS="-Dcom.sun.management.jmxremote.port=22222 
-Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.password.file=/jakarta-tomcat7/apache-tomcat-7.0.2/conf
/jmxremote.password -Dcom.sun.management.jmxremote.access.file=/jakarta-tomcat7/apache-
tomcat-7.0.2/conf/jmxremote.access"

Проследяване на грешки: -

#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 1958536 bytes for Chunk::new. Out of swap space?
#
#  Internal Error (allocation.cpp:215), pid=18658, tid=589781904
#  Error: Chunk::new
#
# JRE version: 6.0_21-b06
# Java VM: Java HotSpot(TM) Server VM (17.0-b16 mixed mode linux-x86 )
# 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 (0x23787400):  JavaThread "CompilerThread0" daemon [_thread_in_native, id=18668, stack(0x231f5000,0x23276000)]

Stack: [0x231f5000,0x23276000],  sp=0x23272e70,  free space=1f723276000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x6a9262]
V  [libjvm.so+0x2b277f]
V  [libjvm.so+0x12e03c]
V  [libjvm.so+0x12e536]
V  [libjvm.so+0x5d67d0]
V  [libjvm.so+0x2f809d]
V  [libjvm.so+0x4f65a9]
V  [libjvm.so+0x27b85f]
V  [libjvm.so+0x278043]
V  [libjvm.so+0x209767]
V  [libjvm.so+0x280f8c]
V  [libjvm.so+0x280839]
V  [libjvm.so+0x66feb6]
V  [libjvm.so+0x66959e]
V  [libjvm.so+0x57a89e]
C  [libpthread.so.0+0x5832]


Current CompileTask:
C2:3230  !   org.apache.jsp.com.common.press_jsp._jspService(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V (4433 bytes)


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x09a21400 JavaThread "http-8080-exec-904" daemon [_thread_in_native, id=17126, stack(SIGTERM: [libjvm.so+0x57aaf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x57aaf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004


---------------  S Y S T E M  ---------------

OS:Red Hat Enterprise Linux Server release 5.5 (Tikanga)

uname:Linux 2.6.18-194.17.1.el5PAE #1 SMP Mon Sep 20 07:34:07 EDT 2010 i686
libc:glibc 2.5 NPTL 2.5 
rlimit: STACK 10240k, CORE 0k, NPROC 114688, NOFILE 1024, AS infinity
load average:0.39 0.54 0.38

CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 15 stepping 11, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3

Memory: 4k page, physical 6228576k(225096k free), swap 6974456k(6974352k free)

vm_info: Java HotSpot(TM) Server VM (17.0-b16) for linux-x86 JRE (1.6.0_21-b06), built on Jun 22 2010 01:04:46 by "java_re" with gcc 3.2.1-7a (J2SE release)

time: Fri Dec 10 14:01:06 2010
elapsed time: 79552 seconds

Благодаря предварително, Амит


person Amit    schedule 14.12.2010    source източник
comment
Изглежда, че ти свършва паметта   -  person Falmarri    schedule 14.12.2010
comment
@Falmari, да, но трябва да се обработва от JVM по-грациозно. Бих опитал Java 6u23, който има много по-нова JVM. (Подозирам, че това е грешка в JVM) Въпреки това може да откриете, че все още получава OOM грешка. Бих направил копие и ще се опитам да видя защо използвате толкова много място. (или увеличете максимума)   -  person Peter Lawrey    schedule 14.12.2010
comment
Можете ли да стартирате 64-битовата версия? Имате 6 Gb памет. Можете да опитате до 4 Gb максимум с 64-битовата версия. (Или разберете защо използвате толкова много памет ;)   -  person Peter Lawrey    schedule 14.12.2010


Отговори (3)


За протокола (и Google), това изглежда като и двете тези грешки, които бяха коригирани в версията 1.6u22 на jdk на sun. Така че, първото нещо, което трябва да направите, е да актуализирате вашата JVM. Ако все още се случва и винаги се случва на определен метод, можете да изключите този метод от компилация (стига да сте наясно с последиците за производителността от това) със следния jvm флаг:

-XX:CompileCommand=exclude,org/apache/velocity/runtime/directive/Foreach,render

(както е предложено тук). Но първо актуализирайте своя jvm.

person Bobby Powers    schedule 14.06.2011

Работите с много JVM аргументи, които засягат паметта. Опитвали ли сте емпирично да премахнете всяка опция, за да видите коя причинява OOM? Този конкретен OOM не идва от Java heap, той идва от собствената C heap на JVM.

person Amir Afghani    schedule 14.12.2010
comment
Съгласен, възможно е комбинацията от опции на OP да задейства грешка в JVM. - person Peter Lawrey; 14.12.2010

Както е посочено от другите отговори / коментари, паметта ви свършва. Предвид вашите JVM настройки, бих казал, че основната причина е 99% вероятно да е изтичане на памет.

Ако сте правили много горещо зареждане в екземпляра Tomcat, това може да се дължи просто на това. Горещото зареждане е известно с изтичане на памет и не можете да направите много по въпроса на практика ... освен да излизате и рестартирате вашия Tomcat по-често.

Другата възможност е вашето приложение да има изтичане на памет. Ако случаят е такъв, тогава ще трябва да използвате инструмент за профилиране на паметта, за да проследите изтичането.

Фактът, че OOME причини срив на JVM, е интересен, но вероятно не е важен. (Изглежда, че JVM се опитва да компилира JIT клас, генериран от JSP, когато паметта му е свършила. Заявеното парче е доста голямо, но това вероятно означава, че имате доста голям/сложен JSP.)

person Stephen C    schedule 14.12.2010
comment
Мисля, че това може да е свързано с грешка в JVM или проблем с компилирането на JIT при компилиране на голяма JSP страница - person 爱国者; 10.07.2012