1

OutOfMemoryError 이후 일반적으로 생성 된 스레드 덤프에는 마지막 가비지 수집기 사이클에 대한 정보가 포함됩니다 (GC 내역 섹션). 하지만이 정보가없는 OutOfMemory 스레드 덤프가 있습니다.GC 기록이없는 OutOfMemory 스레드 덤프

1STGCHTYPE  GC History 
NULL   
NULL   ------------------------------------------------------------------------ 
0SECTION  LOCKS subcomponent dump routine 
NULL   =============================== 

환경이 덤프이 정보를 가지고 있지 않는 이유는 IBM WebSphere 7.0.0.19

누군가가 알아? GC가 전혀 시작되지 않았습니까?

+0

추가 정보를 얻기 위해'jstack [java pid]'를 시도해 볼 수 있습니까? – px5x2

+0

IBM JVM에는이 유틸리티가 없지만 작성된 스레드 덤프 내에서 실행중인 스레드에 대한 정보가 있습니다. 어떤 스레드를 조사해야합니까? – coms

+2

부분적인 답 : GC가 여러분의 경우에 어떻게 동작하는지 (그리고 일반적으로 GC 이력을 모니터링하기 위해), [-verbose : gc] (http://publib.boulder.ibm.com/infocenter/)를 설정하는 것이 가장 좋습니다. javasdk/v6r0/topic/com.ibm.java.doc.diagnostics.60/diag/tools/gcpd_verbosegc.html) 자세한 내용은'nativestdErr.log'를 확인하십시오. –

답변

2

이것은 프로그램이 JVM에서 처리 할 수없는 큰 배열 할당 등의 충분한 메모리를 요청한 경우 발생할 수 있습니다.

2

그런 경우 덤프와 함께 생성 된 Snap.*.trc 파일을 확인해야합니다. 이진 파일이지만 IBM은 추적 파일을 디코딩하기 위해 tool을 제공합니다.

지난번에 OutOfMemoryError이 힙 (또는 기본 메모리) 기아에 의해 트리거되지 않았지만 과도한 가비지 수집 오버 헤드로 인해 GC 기록이없는 파일 인 javacore을 보았습니다. 추적 파일에 명확하게 표시되었습니다.

+0

구문 분석 된 추적 파일에 정확히 표시해야하는 방법은 무엇입니까? – coms

+0

추적 파일을 보관하지 않았으므로 정확한 메시지를 전달할 수 없습니다. 어쨌든, JVM이 덤프를 생성하기로 결정했다면 추적 파일에 그 이유가 언급 될 것입니다. –

관련 문제