IBM HeapAnalyzer 와 MOD4J 로 자바 메모리 누 출 분석
제 가 많이 사용 하 는 것 은 Memory Dump Diagnostic for Java(MDD4J)와 IBM HeapAnalyzer 입 니 다.이 두 도 구 는 거의 모든 JDK 버 전에 서 생 성 된 덤 프 파일 을 지원 할 수 있 습 니 다.사용 하기 전에 두 개의 도움말 파일 에서 지원 목록 을 볼 수 있 습 니 다.
먼저 IBM HeapAnalyzer 에 대해 말씀 드 리 고 다운로드 한 후에 먼저 readme 를 읽 어 보 세 요.이 위 에 HeapAnalyzer 의 사용 방법 이 상세 하 게 적 혀 있 습 니 다.제 가 사용 하 는 2.6 버 전(최신 3.8)에 대해 서 는 명령 행 에<자바 path>자바–Xmx[heapsize]–jar ha 26.jar
hepdump 파일 을 열 면 저 는 보통"Analysis"의"Tree View"를 클릭 하여 루트 노드 에서 메모리 대상 이 분 배 된 정 보 를 트 리 형식 으로 보 여 줍 니 다.
첫 번 째 줄 은 자바.lang.refenrence 라 는 class 와 76 개의 children 이 67%의 사용 한 더미 크기(31M/46M)를 차지 하고 그 자체 가 76bits 만 차지 합 니 다.자바.lang.ref.Refenrence 를 두 번 누 르 면 인용 한 두 개의 키 노드 를 볼 수 있 습 니 다.그 중 하위 노드 인 java.lang.ref.Finalizer 의 67%가 메모리 누 출 을 안내 하 는 문 제 는 인용 에 있어 야 합 니 다.
이어서 한 단계 씩 펼 치 거나'Locate a leak suspect'를 오른쪽 클릭 하여 HeapAnalyzer 가 유출 이 발생 할 수 있 는 곳 을 찾 아 줄 수 있 습 니 다.누 출 은 일반적으로'이례 적'인 인용(하위 노드)을 가 진 클 라 스 에서 발생 하 는데 바로 이러한 생 성 후 방출 되 지 않 고 수천 수백 개의 대상 이 누적 되 어 Outof Memory 를 만 들 었 다.오른쪽 단 추 를 누 른"Go to the largest drop subtrees"도 이 를 원리 로 설정 되 었 습 니 다.
“Search for total size drop” will find a size drop between the total size of a parent and the biggest total size of child of the parent.
누 출 된 점 이 나타 나 기 때문에 모든 하위 노드 가 차지 하 는 메모리 공간 이 크 지 않 지만 엄 청 난 수량 으로 인해 부모 노드 가 차지 하 는 totalk size 가 매우 크다.그러나 반대로 찾 은 점 은 모두 누설 이 발생 한 곳 이라는 주장 은 성립 되 지 않 는 다.그렇지 않 으 면 우리 가 분석 할 필요 도 없다.
더 자세 한 내용 은 이 PPT 를 볼 수 있 습 니 다.
Memory Dump Diagnostic for Java(MDD4J)는 IBM Support Assistant(ISA)의 도구 로 ISA 에 불 러 올 수 있 습 니 다.그것 의 사용 방법 은 HeapAnalyzer 와 유사 하지만,자동 으로'수상 한 누 출 점'을 열거 하여 분석 할 수 있다.근거 로 하 는 것 은'분석 알고리즘 은 부모 대상 과 하위 대상 간 의 대상 크기 의 현저 한 변 화 를 찾 는 것 이다."현저 한 변화 가 발생 한 부모 대상 은 배열 을 바탕 으로 하 는 용기 대상 일 수 있 습 니 다.그들 은 끊임없이 커지 는 하위 대상 을 포함 하고 있 습 니 다."
구체 적 인 사용 방법 은 라 는 글 의 실제 사례 를 참고 할 수 있다.(그러나 글 의 버 전 은 비교적 낮 아야 한다.현재 내 려 갈 수 있 는 2 와 3 버 전 은 다 르 지만 사용 에 방해 가 되 지 않 는 다).
Heapdump 도 구 는 사용 이 간단 합 니 다.어 려 운 점 은'메모리 누 출 의 진짜 원인'을 찾 는 것 입 니 다.보통 여러 개의 hepdump 파일 의 대 비 를 통 해 찾 을 수 있 습 니 다.
비교 분석 은 메모리 누 출 프로그램 을 실행 하 는 동안(즉 자바 로 메모리 유실 시)얻 은 두 개의 메모리 덤 프 를 분석 하 는 데 사용 된다.누 출 된 프로그램 을 실행 하 는 초기 에 발생 하 는 메모리 덤 프 는 기본 메모리 덤 프 라 고 불 리 며 누 출 된 프로그램 이 일정 시간 실행(누 출 허용 정도 증가)한 후에 발생 하 는 메모리 덤 프 를 주 메모리 덤 프 라 고 합 니 다.메모리 누 출 이 발생 한 상황 에서 메 인 메모리 덤 프 는 대량의 대상 을 포함 할 수 있 으 며,이 대상 들 이 차지 하 는 자바 더미 의 공간 은 기본 메모리 덤 프 보다 훨씬 클 것 이다.
더 좋 은 분석 결 과 를 얻 기 위해 서 는 메 인 메모리 덤 프 의 트리거 점 과 기본 메모리 덤 프 의 트리거 점 을 시간 적 으로 일정 거 리 를 벌 려 총 소모 더미 의 크기 를 두 개의 트리거 점 사이 에서 대폭 증가 시 키 는 것 을 권장 합 니 다.
만약 에'메 인 메모리 덤 프'중의 한 대상 의 수량 이'기본 메모리 덤 프'보다 훨씬 많다 는 것 을 발견 하면 이 대상 은 보통 누 출 된 점 이다.그러나 앱 서버 가 시작 되 자마자 힙 덤 프 를 하 는 것 을 피해 야 하 며,그렇지 않 으 면 정상적으로 분배 해 야 할 대상 을 누설 혐의 점 으로 간주 할 수 있다.예 를 들 어 원래 3 일 동안 실행 하면 OOM 이 발생 할 수 있 습 니 다.그러면 쌓 인 크기 를 줄 이 고 OOM 이 일찍 발생 하도록 할 수 있 습 니 다.OOM 이 발생 할 때 까지 4 시간 간격 으로 Heapdump 를 수 동 으로 한 번 씩 실행 합 니 다.이런 동작 들 은 생산 환경 에서 진행 하기에 적합 하지 않 을 수도 있 고 테스트 환경 을 따로 만들어 진행 할 수 있다.
이전 몇 편의 글 에서 소개 한 분석 gc log 와 본 고 에서 말 한 분석 hepdump 는 모두 오프라인 분석 법 이다.그들의 결함 은 코드 로 인 한'성능 저하'의 원인 을 찾 을 수 없다 는 것 이다.에서 보 듯 이 시스템 성능 이 매우 좋 지 않 지만 OOM 이 발생 하지 않 았 기 때문에 매번 full gc 에 쌓 인 후에 계속 감소 하 는 현상 을 메모리 누 출 이 라 고 탓 할 수 없다.마지막 에 모두 회수 되 었 기 때문에 수 동 으로 hepdump 를 하면문제 가 있 을 수 있 는 대상 은 회수 되 어 정확 한 결 과 를 얻 을 수 없다.이 경우 Jprofile 과 같은 JVM 에 직접 추 가 된 도 구 를 사용 하여 모니터링 해 야 합 니 다.
마지막 으로 구 글 에 일이 닥 치지 않도록 수 동 으로 hepdump 를 만 드 는 방법 을 첨부 합 니 다.
Linux/AIX 환경 에서
Kill-3 pid 명령 을 사용 하여 덤 프 저장 소 를 호출 합 니 다.
Windows 환경 에서
1.JVM 대상 이름 찾기.
<wsadmin> set objectName [$AdminControl queryNames
WebSphere:type=JVM,process=<servername>,node=<nodename>,*]
2.JVM MBean 에 generateHeapDump 동작 을 호출 합 니 다.<wsadmin> $AdminControl invoke $objectName generateHeapDump
만약 상술 한 방법 이 생 성 되 지 않 았 다 면 아래 의 설정 을 진행 하 십시오.
액세스 관리 콘 솔"서버">"응용 프로그램 서버">Server 1(또는 덤 프 된 서버 의 이름 을 가 져 오 려 면)>"프로 세 스 정의">"환경 항목"으로 이동 합 니 다
"새로 만 들 기"를 누 르 십시오 "이름"필드 에 IBM 을 입력 하 십시오.HEAPDUMP(기본적으로 열 림)."값"필드 에 true 를 입력 하 십시오
"확인"을 누 르 십시오 3~5 단 계 를 반복 하지만 IBMHEAPDUMP_OUTOFMEMORY 를 true 로 설정 합 니 다.. 결 성 된 경우~/WebSphere/APServer/디 렉 터 리 에 메모리 덤 프 를 만 듭 니 다(WebSphere Application Server V6.x 의 경우 결 성 된 디 렉 터 리 는~/WebSphere/APServer/profiles/default).덤 프 대상 을 다른 디 렉 터 리 로 지정 하려 면'환경 항목'으로 옮 기 고'새로 만 들 기'를 누 르 면 IBMHEAPDUMPDIR 는 적당 한 디 렉 터 리(예:/heapdumps)로 설정 한 다음'확인'을 누 르 십시오
4.567917.'저장'을 클릭 하고 다음 화면 에서'저장'을 다시 클릭 합 니 다 "서버">"응용 프로그램 서버">server 1(또는 덤 프 된 서버 의 이름 을 가 져 오 려 면)>"프로 세 스 정의">"자바 가상 컴퓨터"로 이동 합 니 다 '상세 쓰레기 회수'를 선택한다
4.567917.'저장'을 클릭 하고 다음 화면 에서'저장'을 다시 클릭 합 니 다
서버 를 다시 시작 합 니 다 명령 프롬프트 를 열 고/WebSphere/AppServer/bin 디 렉 터 리 로 이동 합 니 다 kill-3 XXXX 명령 을 통 해 덤 프 를 호출 하 는데 그 중에서 XXXX 는 프로 세 스 표지 이다
WebSphere 가 HP-UX 에서 실행 된다 면 필요 합 니 다.
액세스 관리 콘 솔"서버">"응용 프로그램 서버">Server 1(또는 덤 프 된 서버 의 이름 을 가 져 오 려 면)>"프로 세 스 정의">"환경 항목"으로 이동 합 니 다 "일반적인 매개 변수"에 입력:-Xrunhprof:depth=0,heap=dump,format=a,thread=n,doe=n 부족 한 경우~/Websphere/AppServer/디 렉 터 리 에 메모리 덤 프 를 만 듭 니 다.덤 프 대상 을 다른 디 렉 터 리 로 지정 하려 면 HProf 인자 file=/heapdumpdir/hpro.txt 를 추가 하 십시오.그 중에서 hepdumpdir 는 적당 한 디 렉 터 리 이 고 hprof.txt 는 적당 한 파일 이름 입 니 다.여러 개의 메모리 덤 프 를 만 들 었 다 면 모든 메모리 덤 프 를 같은 hprof.txt 파일 에 추가 합 니 다 "자세 한 쓰레기 수 거 방식 사용"을 선택 하 십시오
서버 를 다시 시작 합 니 다 kill-3 XXXX 명령 을 통 해 덤 프 저장 소 를 만 듭 니 다.그 중에서 XXXXXX 는 프로 세 스 표지 입 니 다 따로 지정 하지 않 으 면~/WebSphere/AppServer/디 렉 터 리 에 hprof 덤 프 를 만 들 고 파일 이름 은 자바.hprof.txt 와 유사 해 보 입 니 다
응용 프로그램 서버 를 닫 고 hprof 덤 프 파일 을 이동 합 니 다.응용 프로그램 서버 를 정확하게 닫 은 후에 야 hprof 덤 프 파일 이 완전 합 니 다
4주의:모든 hprof 덤 프 가 HEAP DUMP BEGIN 과 HEAP DUMP END 라 는 두 그룹의 표 시 를 포함 하고 있 는 지 확인 하 십시오.hprof 덤 프 의 이 두 조 의 표시 가 완비 되 지 않 으 면 이 덤 프 가 완전 하지 않 고 분석 에 사용 할 수 없다 는 것 을 나타 낸다
비고:
본문 전재:http://www.hashei.me/2009/07/heapanalyzer-and-mod4j-introduction.html
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Is Eclipse IDE dying?In 2014 the Eclipse IDE is the leading development environment for Java with a market share of approximately 65%. but ac...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
