JMC, JFR 을 이용해서 메모리 누수를 진단해보자! Memory Leak 발견하기 메모리 누수로 인한 잦은 GC로 어플리케이션이 느려질 수 있으며, 결국 OutOfMemoryError가 발생한다. 메모리 누수를 JFR을 이용해서 찾을 수 있다. Old Generation에 GC가 발생했는데도 꾸준히 살아있는 객체들의 갯수가 증가한다면 메모리 누수를 의심할 수 있다. 메모리 누수는 오랜 기간 쌓인 로그를 봐야할 경우가 많기 때문에 JMC을 이용해서 로그를 잘 남겨놔야 한다. ( JMC Event Trigger를 이용해서 특정시간마다 특정기간동안 JFR 을 돌려서 기록할 수 있다) Memory Leak 클래스 찾기 메모리 누수가 발견되었다면, 어떤 클래스에서 메모리 누수가 발생하는지 찾아야한다. 메모리 ..

(프로덕션 환경에서 사용할려면 라이센스 필요, 그외에는 무료로 사용 가능) JMC 는 두 가지 주요 목적으로 사용될 수 있다 1) JVM의 상태를 모니터링 2) Java Flight Recorder를 이용해서 생성한 덤프 파일 분석 JMC, JFR을 통해 무엇을 할 수 있는지 살펴보자 ※ 주의! 어플리케이션 성능 JFR을 이용해서 어플리케이션을 모니터링할 때는 성능을 주의해야한다. JFR을 이용해서 얻을 수 있는 데이터 종류가 많기 때문에, 모든 것을 측정하려고 하면 어플리케이션에 부하가 심해진다. 따라서 원하는 데이터만 골라서 기록해야 한다. JFR은 데이터의 종류 뿐만 아니라 데이터를 얼마나 자주 측정할지 등 기본적인 설정이 필요하다. JFR은 미리 설정된 프로파일을 제공한다. (default.jfc..

1. 서바이버 스페이스 이해하기 Young Generation에서 객체들의 이동은 다음과 같다. 2. 서바이버 스페이스의 존재 이유 - 몇번의 Minor GC 동안 영 제너레이션 내에 객체가 남아있도록 설계하여, 올드 제너레이션으로 승격될 만큼 오래 살아남지 못한 객체들은 그 전에 제거한다. - S0S1을 핑퐁을 쳐가며 오래 살아남지 못할 객체들은 Old Generation 전에 소거한다. 3. 서바이버 스페이스 오버플로우 서바이버 스페이스가 작아서 또는 어떤 이유로 꽉차게 되면 Minor GC발생 시, 객체가 에덴에서 올드 제너레이션으로 바로 승격된다. 오랫동안 사용되지 않을 객체라도 서바이버의 필터링을 거치지 못하기 때문에 올드 제너레이션으로 이동하게 되어 Full GC를 초래한다. 서바이버 스페이스..

튜닝 목표 : 잘 튜닝된 G1은 Full GC가 발생하지 않아야 한다! Full GC 예방 방법 1) 힙 전체 크기 늘리기 & 제너레이션 간의 비율 조정 2) 백그라운드 스레드의 개수 늘리기 3) 백그라운드 스레드 자주 실행하기 4) 혼합 GC의 작업량 늘리기 MaxGCPauseMillis 를 통한 쉬운 튜닝 G1을 튜닝하는 방법은 많지만, G1의 목표중 하나는 손 쉬운 튜닝이다. G1은 Throughput Collector 에서 봤던 플래그인 -XX:MaxGCPauseMillis=N 을 통해서 간단히 튜닝할 수 있도록 제공한다. -XX:MaxGCPauseMillis = N (디폴트 200ms) G1은 어떤 단계인지 상관없이 Stop-the-world가 발생하면 플래그 값을 읽고, 플래그가 기준값을 넘어..

CMS와 마찬가지로 G1의 목표는 Full GC가 발생하지 않는 것 Full GC 가 발생하는 네 가지 경우는 다음과 같다 1) Concurrent GC Fail , 동시 병렬모드 실패 - Concurrent GC는 표시 단계를 거쳐서 혼합 컬렉션때 가비지가 소거된다. 그런데 혼합 컬렉션이 진행되기 전, 표시 단계에서 올드 제너레이션이 가득찰 경우 G1은 표시 단계를 중단한다. - 이 때, 힙 크기를 늘리거나, 표시 단계를 빨리 시작하거나, 표시 단계의 스레드 수를 늘려서 표시 단계가 더 빨리 수행되도록 튜닝해야 한다. 2) 승격 실패 ( 영 -> 올드 ) - 혼합 컬렉션이 시작되었지만, 혼합컬렉션에 의해 소거되는 올드 제너레이션의 영역보다, Minor GC로 승격되어서 올드 제너레이션 영역으로 이동하는..

G1(Garbage First) 이해하기 힙을 디폴트 2048개의 영역으로 나누어서 영역마다 가비지 컬렉을 실행한다. 각 영역은 영, 올드 제너레이션 어떤 용도든지 사용될 수 있다. 각 영역은 서로 인접할 필요 없다. 영역을 많이 나눔으로써, 미참조 객체를 일부 영역들에 모아서 남겨둘 수 있다. 따라서 가비지만 모인 영역들만 집중적으로 처리하여 가비지 컬렉을 빠르게 끝낼 수 있다. 가비지를 우선(Garbage First, G1)이다. G1 기본동작 1) Minor GC : Stop-the-world를 발생시킴 2) Concurrent GC 2-1) 표시 2-2) 혼합 컬렉션 3) Full GC : 피하는 것이 목적 1) Minor GC - 빈 공간은 어디에도 속하지 않는다. G1이 필요하다고 생각하면 아..

CMS 는 Default로 PERM 제너레이션을 처리하지 않는다. 때문에 PERM 영역이 가득차면 CMS는 Full GC를 수행한다. -XX:CMSPermGenSweepingEnabled ( Default : false ) -XX:CMSInitiatingPermOccupancyFraction=N ( Default : 80% ) -XX:+CMSClassUnloadingEnabled ( Default : true ) CMSPermGenSweepingEnabled => PERM 이 CMS의 스레드에 의해 처리되도록 지정한다 CMSInitiatingPermOccupancyFraction = N => PERM의 N%가 가득 찼을 때, PERM 영역을 처리하는 스레드를 실행시킨다. CMSClassUnloadingE..

CMS 힙 크기 튜닝하기 CMS는 힙과 제너레이션의 크기를 결정하기 위해 Throughput Collector에서 봤던 플래그 MaxGCPauseMillis=N , GCTimeRatio=N 두개를 사용한다. [JVM] Throughput Collector - 힙 사이즈 튜닝하기 CMS Concurrent Mode 튜닝하기 CMS를 튜닝할 때 가장 중요한 것은 Full GC 가 발생하지 않도록 하는 것! CMS는 Full GC가 발생하지 않는것이 가장 이상적이다 CMS의 영 제너레이션은 Full GC 가 발생하지 않으면 절대로 크기가 변경되지 않는다 CMS의 목표는 Full GC가 발생하지 않는 것이므로, 잘 튜닝된 CMS 어플리케이녀은 절대로 영 제너레이션의 크기가 변경되지 않는다. CMS 올드 제러네이..

기본동작 1) Minor GC - 모든 어플리케이션 스레드를 멈춤 2) 동시 병렬 컬렉션 - Full GC 가 발생하지 않도록 백그라운드에서 GC 3) Full GC - 어쩔수 없는 경우 Full GC CMS Collector Minor GC 동작 과정 요약 - Throughput Collector 와 동일 CMS Collector Minor GC Log CMS Collector 동시 병렬 컬렉션 동작 과정 요약 CMS Collector 동시 병렬 컬렉션 GC Log Step 1. Initial Mark - 모든 어플리케이션 스레드가 멈춘다(Stop-the-world) Step 2. Mark - 어플리케이션 스레드를 멈추지 않는다(동시 병렬 실행) - 아무런 정보가 없다. 단지 표시만 하는 단계 Step..

고려사항 - 전체 힙 크기 - 올드 / 영 제너레이션의 비율 - GC로 인한 중단시간 - 트레이드 오프 : 힙크기 증가 => Full GC 중단 횟수 감소 => Full GC 중단시간 증가 처리율 / 힙크기 그래프 - 힙크기는 크다고 좋은게 아니다 - 256MB의 작은 힙에서는 전체시간의 35%정도를 GC를 수행한다 - 힙크기가 일정크기를 넘어서면 처리율이 하락 => Full GC 수행시간 증가! - 최적의 처리율을 갖는 힙 크기를 결정하는 것이 중요 최적의 힙 크기 결정하기 - 어플리케이션 실행 & 모니터링의 반복? (X) - Adaptive Size Policy 자동크기조정 기능을 사용하고 JVM이 알아서 결정하도록 내버려두자! 무엇이 "최적"일까? - JVM에게 "최적"이 무엇인지 성능 목표를 제시..