목적 : 우리는 특정 서비스의 성능을 측정할 때 JVM의 상태를 체크 해야 한다. JVM을 모니터링 하는 방법으로 여러가지 Tool을 이용하는 방법이 있다.
하지만, 이러한 Tool에서 제공하지 않는 좀더 복잡한 JVM의 상태를 모니터링 해야 하는 필요성이 있다.
이때, 우리는 쉽게 모니터링 할 수있는 방법이 없으며, JVM을 직접 접근하여 내부를 분석해야 한다.
이를 위한 기술을 정리할 것이다.
대상자 : JVM을 모니터링 및 Troubleshooting을 하는 사람 대상, 설명의 깊이는 가이딩을 할수있는 단계까지
발표 순서
JVM에 대해서 --> JVM에 접근하는 방법 중 우리가 쉽게 접근해 왔던 방법들 --> 이 들이 사용하는 기술들 나열 --> 이들이 제공하지 못하는 기능들 --> 이를 위해서 직접
JVMTI에 접근해야 하는 Needs --> JVMTI에 대한 자세한 설명 --> JVMTI를 가지고 JVM 모니터링 하는 방법 예제를 통해 설명 -->
우리가 이러한 리서치를 하는 이유
- 많은 소프트웨어는 Memory Leak이 발생하는 문제점을 가지고 있다
- 어떻게 메모리 Leak이 발생하고 있는지를 찾아야 하는데...
- 효과적으로 진단하는 방법에 대해서 일단 알아야 하겠지??
Table Of Contents
1. JVM의 Monitoring의 필요성
목적 : Needs 정리
2. JVM 내부 구조
목적 : 무엇을 모니터링 해야 하는가?
3. JVM Monitoring 방법 및 한계점
목적 : 쉽게 접근하기 쉬운 방법들을 정리함으로써
3.1 여러가지 공개 Tools
Jstack, Jconsole, Yourkit Java Profiler 등등
목적: 공개 Tool 들이 가지는 장점 및 기능을 소개함으로써 상황에 따라 적합한 Tool을 사용할 수 있도록 하기 위해
3.2 JMX : 모니터링 및 관리 API
목적: JVM을 모니터링하는 방법을 소개함으로써, JMX를 기반으로 확장 가능하도록 기반 기술 익히기 위해
3.3 한계점
목적 : 공개 Tool 또는 JMX의 한계점을 알고 있으면, JVMTI를 통해 직접 성능 분석 도구를 만들어야 할 상황을 쉽게 인지할 수 있음
4. JVMTI란
목적 : 어떤 경우에 JVMTI 기술을 사용하는가?
4.1 아키텍쳐
4.2 사용 방법
java 5 이상에서 제공
-javaagent:[=]
load Java programming language agent, see java.lang.instrument
: JVMTI가 자바로 구현된 agent를 활성화 한다는 의미
: JavaAgent는 BCI 기술
JavaAgent와 JVMTI가 모두 java 5 에서 지원됨
JavaAgent와 JVMTI는 몇가지 특징을 공유
Sun이 Java 5에서 JVMTI와 JavaAgent를 제공하면서 의도한 것은 이 두가지 방법을 상호 보완적으로 사용하라는 것이다.
즉, JVM 자체를 프로파일링하는 것은 여전히 JVMTI와 같은 C 언어 레벨의 API를 사용하되,
BCI를 통해 특정 클래스의 액션을 프로파일링하는 것은 JavaAgent와 같은 Java 언어 레벨의 API를 사용하기를 권고한다/
여기서 JMX의 Platform MBean 기능까지 추가되디었으니, 이제 Java는 성능 관리에 있어 그 어느때보다 폭 넓은 기능을 제공하는 셈
- JMX의 Platform mxBean은 성능 문제를 분석하는 또 다른 표준으로 제공
- Platform MXBean을 이용하면 JVMPI/JVMTI등의 C Interface를 통해서만 얻을 수 있었던 유용한 정보들을 매우 쉽게 얻을 수 있다.
- 하지만 성능 문제를 본격적으로 분석하기에는 부족한 면이 많으며, 앞으로 API 개선을 통해 실질적인 성능 정보를 제공해 줄 것을 기대한다.
- JMX API를 이용하여 자신만의 성능 분석 Tool을 만들어 낼 수 있다.
JVMTI = JVMDI(JVM Debugging Interface) + JVMPI(JVM Profiling Interface)
memory tracking of the JVMTI
- Eclipse TPTP(Test and Performance Tools Project) JVMTI(JVM Tool Interface) 프로파일링 에이전트 기능에 대한 관련 배경지식 제공
- JVMTI 인터페이스
실행 분석 agent : 각 메소드에 소요된 시간, 메소드 호출 수 및 전체 호출 그래프와 같은 실행 통계를 수집하는데 사용된다
힙 분석 agent : 메모리 사용량 통계를 생성하는데 사용된다. 메모리 활성 크기 및 활성 인스턴스와 같은 오브젝트 할당 세부 사항을 수집한다
스레드 분석 agent : java 애플리케이션에 의해 파싱된 스레드에 대한 세부 사항을 얻는데 사용된다.
'Technical Note'에 해당되는 글 134건
- 2015.01.02 jvm 리서치 준비
- 2015.01.02 GC 튜닝
- 2015.01.02 AspectJ의 Load Time Weaving (LTW)
- 2015.01.02 자바 코드 커버리지 툴(Java Code Coverage Tool)
- 2015.01.02 Full GC 발생시 Heap Dump & Thread Dump 뜨는 방법
GC 튜닝
1 Old 영역의 크기 결정
old는 상시적으로 유지되는 객체의 크리를 추정해서 해당 대비 4배 정도로 잡습니다.
Tenured 영역의 50% 를 넘어설 때, 첫 Tenured GC가 발생합니다. 튜닝이 제대로 되면 40%에서 유지시킬 수 있습니다.
2. New에서 old로 넘어가기 위한 threashold 를 증가
new 영역(Young 영역)은 eden과 survivor 영역(s0, s1 영역으로 다시 구분)으로 구성되는데, 최초 객체 생성시 eden에 생성됩니다.
eden 영역이 꽉차면 minor gc가 발생하고 살아남은 객체들은 survivor 영역(s0)으로 이동합니다.
다시 eden 영역이 꽉차면 minor gc가 발생하고 eden 영역에서 살아남은 객체와 s0에서 살아남은 객체가 s1 영역으로 이동합니다.
다시 eden 영역이 꽉차면 minor gc가 발생하고 eden 영역에서 살아 남은 객체와 s1에서 살아남은 객체가 s0으로 이동합니다.
즉, 영원히 살아남는 객체는
eden -> s0 -> s1 --> s0 --> s1 --------> old 순으로 이동합니다.
survivor 영역에서 old로 언제 이동시키는가?
이결정에 대해 default gc는 두가지 파라미터를 제공합니다
s0, s1의 이동횟수 threshold값 (기본 31) 과 s0 영역의 사용량의 Threshold 값입니다
이 파라미터를 사용해서 eden 영역과 s0 영역의 크기는 다음과 같이 예측 가능하다
이동횟수를 1로 잡고 eden 영역과 s0 영역을 동일하게 잡는다
old 영역은 충분히 커야 합니다
이후 부하를 가해 변화량을 측정합니다
eden 에서 살아남은 s0 의 메모리크기는 Mimor gc 시 객체의 생존율입니다
이동횟수가 1이기때문에 minor gc 발생후, s0 영역에서 old로 바로 집입하기 때문에 old 영역의 증가율이 s0에서 생존율입니다
http://lsleez.tistory.com/entry/GC-%ED%8A%9C%EB%8B%9D%EC%97%90-%EB%8C%80%ED%95%9C-%EC%9D%98%EA%B2%AC%EB%93%A4
System.gc()를 disable 시키는 방법
-XX:+DisableExplicitGC 셋팅
추가사항
1) PermSize와 MaxPermSize는 동일하게 설정하는게 좋음
2) 튜닝을 아무리 잘해도 Tenured GC는 발생함
이유는 아무리 eden 영역이 커도 old 영역으로 promotion되는 객체는 존재할 수 밖에 없기 때문이다.
그리고 promition 되는 객체들이 아주 미량이나마 존재하는한 언젠가는 Tenured GC가 발생한다.
그렇기 때문에 JVM 전체 메모리를 아주 크게 설정하는게 가장 좋은 답은 아니다.
튜닝의 순서 application --> 공통 유틸 --> 미들웨어 --> jvm --> os 순으로
궁금증
RMI에서 하는 GC란??
GC Viewer Tool
| 자바의 경우 가비지 컬렉션은 매우 중요한 메키니즘 입니다. 특히나, 자바로 서버를 개발할 경우에는 필히 알고 있어야 되겠죠.. 이러한 가비지 컬렉션을 통해서 메모리의 상태를 비주얼 하게 보게 된다면, 서버 모니터링시에 매우 도움이 될 것입니다. 아래는 가비지 컬렉션을 보여주고 있는 툴들입니다. http://java.sun.com/performance/jvmstat/ http://docs.hp.com/en/5991-6757/ch03s04.html http://java.sun.com/developer/technicalArticles/Programming/GCPortal/ http://shark.ucsf.edu/gc/viewer/index.html http://www.javaperformancetuning.com/tools/gcviewer/index.shtml |
1. 다운 사이트
- visualgc - Sun의 jvmstat.
- GCPortal - GC관련 아티클 및 툴.
- HPjmeter - HP용 GC Viewer.
- GC Viewer - GC Viewer1.
- GC Viewer - GC Viewer2.
2. 특징
- garbage collection데이터를 통해 성능 지표(throughput, accumulated pauses, longest pause 등)를 계산하여 보기 좋게 보여줌
- GC Viewer같은 경우는 csv 포멧으로 데이터를 import할 수 있음
- generation sizes를 변경하고 heap size를 설정하는 등을 통해 gc를 튜닝하는데 유용함
3. 플랫폼 별 설정 방법
- Sun JDK 1.4/1.5 : -Xloggc:<file> [-XX:+PrintGCDetails]
- Sun JDK 1.2.2/1.3.1/1.4 : -verbose:gc
- IBM JDK 1.3.1/1.3.0/1.2.2 :n -verbose:gc
- HP-UX JDK 1.2/1.3/1.4.x : -Xverbosegc
- BEA JRockit 1.4.2/1.5 : -verbose:memory
- 표준 : -Xloggc:<file> -XX:+PrintGCDetails
4. GC관련 아티클
- VMFlags - IBM/Sun JVMs 파라미터 정리
- IBM Garbage Collection and Storage Allocation Techniques - IBM garbage collector에 대한 설명서
- Tuning Whitepaper - Sun의 Java Tuning Whitepaper
- List of Java 6 -XX options - GC의 간략한 설명
Load Time Weaving이란 말 그대로 클래스가 로드되는 시점에 Weaving 작업을 수행하는 것을 의미한다.
전통적으로 AspectJ 에서는 ajc(AspectJ Compiler)라는 컴파일러를 사용해서 사용자가 작성한 Class 파일이나 jar 파일을 컴파일 시간에 Weaving 하는 방식을 지원했다. 비록 이 방법이 아직까지도 가장 보편적이고 또 편리한 방법이긴 하지만, 컴파일시 Weaving 은 역시 불편한 방법이다. 하지만, 성능면에서는 가장 유리한 방법이라는 것은 염두해 두자
|
Code Coverage 분석을 위한 Tool들은 오픈 소스부터 시작해, 상용 솔루션까지 많은 Tool 들이 있습니다.
다음은, 무료 배포되고 있는 Java Code Coverage Tool을 비교 분석한 매트릭스입니다.
다음 표와 같이 각 Tool 마다, 제공되는 기능이 다양합니다.
저의 경우는 MC/DC Coverage 분석이 필요하기 때문에, 대부분 CodeCover를 사용합니다만, 간단하에 사용할 때에는 EMMA를 사용하기도 합니다. 분석 영역이 적은 만큼 빠르기 때문이죠. CodeCover로 MC/DC Coverage 까지 분석하는 경우, 클래스 갯수가 500 가 넘어가면, 한 번 분석하는데 굉장히 오래 걸립니다.
필요에 따라, 다음과 Tool 들 중에서 선택해서 사용하면 되겠죠.
| Statement Coverage | Decision Coverage | MC/DC Coverage | 실행 환경 | Report | |
| CodeCover | O | O | O | ANT Command Line Eclipse | Velocity 기반 Template 제공 HTML, XML |
| Cobertura | O | O | ANT Command LIne | HTML | |
| EMMA (EclEMMA) | O | Command Line Eclipse | HTML, XML, TXT | ||
| Coverlipse | O | Eclipse | N/A |
무료 배포 Code Coverage 분석 Tool 들이 더 있습니다. 추후 추가하도록 하겠습니다.
Full GC 발생시 Heap Dump & Thread Dump 뜨는 방법
Full GC 발생시 아래 사항을 숙지하여 Heap Dump를 떠야 할 상황에 잘 수행토록 하자
1. PID 알기
2. GC 로그 위치 확인
3. GC가 발생했을 시 로그 확인
GC 로그 파일을 Tail 걸었을 때 아래 첫번째 굵은 값이 2 : GC Type : old Generation GC or Full GC
마지막 굵은 값이 11.467193 가 2초 이상 걸리는 로그가 반복 되때 일반적으로 메모리 부족으로 인한 Full GC가 일어났다고 보면 됨
< GC: 2 1 .......... 11.467193>
4. Heap Dump & Thread Dump 뜨기
kill -3 PID
5. Heap Dump 파일 위치 확인
파일이 크기 때문에 다 생성되기까지 시간이 걸림, ls -l로 확인해서 size가 더이상 변하지 않으면 다 생성된 거임
6. Thread Dump 파일 위치 확인
분석 시작
