튜닝 목표 : 잘 튜닝된 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에게 "최적"이 무엇인지 성능 목표를 제시..

Throughput Collector Minor GC 동작 과정 요약 Throughput Collector Minor GC Throughput Collector Minor GC Log PrintGCDetails 플래그를 활성화 시켜서 발생한 Minor GC 로그를 보면 다음과 같다 Throughput Collector Full GC 동작 과정 요약 Throughput Collector Full GC Log [출처] [JVM] Throughput Collector - GC Log

4개의 GC 알고리즘에 공통적으로 적용되는 기본적인 튜닝 방법에 대해 알아보자 Heap Size 힙이 너무 작다면 너무 자주 GC가 일어날 것이고, 힙이 너무 크다면 중단은 줄어들지만 Full GC가 발생했을 때 중단 시간이 너무 길어진다. OS 메모리와 힙 사이즈 힙 사이즈는 [물리적 RAM - (OS에서 사용하는 RAM)] 보다 작게! OS는 스와핑, Paging을 통해 메모리를 가상화시켜서 관리한다. 예를들어 OS는 실제로 PC의 RAM은 8GB이지만 가상화를 통해 16GB로 보이도록 제공한다. 이때, 실제로 물리적인 RAM은 8GB이기 때문에, 나머지 8GB를 디스크에서 가져와서 사용한다. 이 과정은 사용자에게는 투명하지만 내부적으로 디스크에 있는 데이터에 접근할때마다 느려질 것이다. 힙 크기를 ..

GC 알고리즘을 살펴보기 전에, GC 기본 개념에 대해 다시 살펴보자 [JVM] GC 기본개념 - JVM메모리 구조 / Minor GC / Full GC 자바에서 가비지 컬렉터는 대부분의 객체는 한번 쓰고 버려진다는 사실을 이용해서 설계되었다. JVM에서 사용할 수 있는 가비지 컬렉터에는 여러 종류가 있다 모든 가비지 컬렉터는 힙을 별도의 제너레이션으로 나눠서 작업한다 Young 영 / Old 올드 영 제너레이션은 Eden 에덴과 Survivor Space 서바이버 스페이스로 나뉜다 Minor GC 모든 GC 알고리즘은 영 제너레이션에서 수집하는 동안 모든 어플리케이션 스레드를 중지시킨다. 매우 빨리 일어나는 작업이다. 객체는 처음 생성되면 먼저 힙의 영 제너레이션에 할당된다. 영 제너레이션이 가득차면 ..