힙 덤프 분석 - - 우수한 라이브러리

내가 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=50 및 Dsun.rmi.dgc.server.gcInterval=43200000 -Dsun.rmi.dgc.client.gcInterval=43200000힙 덤프 분석 -

의 GC 간격으로 구성 GC와 maxmimum 힙 크기 -Xms4096m -Xmx4096m -Xmn1024m의 4 기가있는 응용 프로그램을 실행하고 있습니다에서 OutOfMemory 예외의 근본 원인을 찾기가 갑자기 내 응용 프로그램의 메모리가 힙 갔다 예외와 나는 같은 기회에 스레드 덤프와 힙 덤프를했다. 스레드 덤프를 분석 할 때 hashMap 및 arrayList에 값을 생성하여 스레드가 멈 춥니 다. ByteArrayOutStream 스레드 중 하나에서 잠금을 만들었습니다.

이클립스 메모리 분석기 도구에서 힙 덤프를 분석하는 경우 bytearray 개체가 거의 1 힙의 힙을 차지하고 있음을 분명히 알 수 있습니다. GCViewer에서는 초 단위의 피크가 있음을 보여줍니다. 나는 왜 갑자기 Byte Array 객체가 1 기가의 공간을 사용했는지에 대한 단서가 적다. 범인을 좁히기 위해 나를 도와 줄 수 있습니까?

는

- 응용 프로그램 서버 - 웹 로직 12C 이클립스 메모리 분석기 도구에서 힙 덤프를 분석에

출처

2016-10-12 Arun

제공되는 정보로 말하기가 어렵습니다. 소비하는 메모리 코드에 대해 더 자세히 설명해 주시겠습니까? – Minh

그냥 바이트 배열을 아는 것이 도움이되지 않습니다. 무엇이 잘못되었는지 알기 위해 배열을 사용하는 응용 프로그램의 객체를 찾아야합니다. MAT를 사용하면 계층 구조를 포함하는 객체로 이동할 수 있습니다. –

더 많은 코드 정보가 도움이 될 것입니다. 제공되는 jvm 플래그를 사용하여 기본 응용 프로그램을 실행해도 아무 것도 복제하지 않습니다. –

, 그것은 명확하게 객체가 힙의 거의 1 연주회를 차지했다 BYTEARRAY 말한다.

MAT의 GC 루트 기능에 대한 최단 경로를 사용하여 바이트 배열에 보유 된 참조를 확인합니다.

출처

2016-10-12 07:57:44 the8472

합병을 시도한 모든 참조가있는 GC 뿌리의 최단 경로는 다음과 같습니다. 참조를 보이지 않습니다. Dominator 트리를 사용하여 메모리 주소 "0x74d407870"및 바이트 []의 특정 값을 가진 byt 배열 objcet을 표시합니다. 이 외 다른 방법은 없나요? – Arun

개체가 OOME으로 인해 할당 된 후 도달 할 수 없게 될 가능성이 있습니다. 어쩌면 당신은 ByteArrayOutStream에 큰 것을 직렬화하려고 시도 할 것입니다. 물론 ByteArrayOutStream은 사용될 때까지 메모리에 보관됩니다. – the8472

당신은 정확합니다. 객체를 직렬화하려고 시도 중입니다. JVisualVM에서이 참조 (Java 프레임) - value : byte [] # 65581 (1,073,790,734 items) <- buf (자바 프레임) 클래스 : java.io.ByteArrayOutputStream, value : byte [] # 65581 (1,073,790,734 items) <- 아웃 (자바 프레임) - 클래스 : java.io.ObjectOutputStream $ BlockDataOutputStream, 값 : java.io.ByteArrayOutputStream # 12 <- bout (Java 프레임) - 클래스 : com.terracotta.toolkit .object.serialization.SerializationStrategyImpl $ SerializerObjectOutputStream, 값 : java.io.ObjectOutputStream $ BlockDataOutputStream # 13' – Arun

힙 덤프 분석 -

답변

관련 문제