Java G1 GC의 특성에 따른 Full GC 회피 튜닝 방법

Java 6 중반부터 G1 GC가 나오면서 이 새로운 Java VM GC 정책을 두고 성능 튜닝을 어떻게 할지 고민이 많은 것 같다.

일단 생소하기 때문에 어렵다.

그런데 경험들이 조금씩 쌓이면서 문제점도 꽤 발견되는 것 같다.

먼저 G1GC를 이해하는 데 유용한 사이트이다.


JDK 7부터 기본이 된 G1(garbage first) GC는 JVM의 Heap 메모리를 1MB 정도 크기의 region들로 나눠서 region별로 generation을 지정하여 상당히 효율이 좋지만 튜닝하는 게 까다롭다.
(새로운 메모리 처리 구조에 대한 튜닝 경험도 많이 부족해서 더욱 까다롭게 느껴지는 것 같다.)

지금까지 널리 알려진 문제로는 첫째, perm generation collection을 full gc때만 하는 문제가 있다.
즉, 클래스 언로딩을 full gc때만해서 자주 재배포가 발생하는 코드가 있는 경우 문제가 될 수 있다.
앞으로는 perm generation을 완전히 없애도록 JVM의 방향을 잡고 있기 때문에 당분간 이 문제는 해결하지 않을 것으로 보인다.

둘째, G1 GC에서 거대 객체(humongous object)라고 부르는 메모리 사용량이 큰 객체들에 대한 처리는 아직 최적화되지 않았다. 보통 한 region의 50% 크기를 넘으면 거대 객체로 분류되는데 G1 GC의 한 region 크기는 보통 1MB~32MB 정도이므로 거대 객체를 많이 사용해야 한다면 다른 gc policy를 선택하는 게 맞을 것이다.

셋째, young generation 즉, eden space에 대한 gc는 매우 빠르게 처리되지만, 일단 old로 넘어간 객체들의 컬렉션은 실행이 잘 되지 않는다는 것이 경험적으로 파악되었다.

그래서 full gc를 피하기가 어렵다. (그런데 full gc 가 상대적으로는 다른 JVM에 비해 매우 빠르긴 하다.)
full gc가 시간이 짧다고 해도 성격 상 JVM의 모든 프로세싱을 중지시키는 STOP-THE-WORLD 방식이기 때문에 문제가 없는 것은 아니다.
(G1 GC에서는 young이든 old이든 copy하는 경우는 모두 STW 방식이다)

때문에 여러 가지 블로그나 기사를 통해 full gc를 회피할 수 있는 옵션을 찾아봤지만 실제로는 잘 동작하지 않았다.

그런데 Spark와 같은 대용량 메모리 처리시스템을 다루는 이들이 이 old generation region들에 대한 gc 옵션을 찾아놓았다.
다음 사이트의 기사를 읽어보자.
이들이 내세운 플래그는 바로 다음이다.

-XX:+UseG1GC -XX:+UnlockDiagnosticVMOptions -XX:+G1SummarizeConcMark -XX:InitiatingHeapOccupancyPercent=35 -XX:ConcGCThread=20
-XX:+PrintFlagsFinal -XX:+PrintReferenceGC -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintAdaptiveSizePolicy
이 옵션들 중 full gc를 회피하기 위해 알아둬야 할 G1 GC의 튜닝에관련된 핵심 정보는
  1. ConcGCThread갯수를 좀더 많이 사용하도록 옵션 설정
  2. InitiatingHeapOccupancyPercent옵션을 좀더 작게 설정하는 것이다.(기본값은 45이다.) 
두번째 옵션은 언제 eden이 아닌 old heap 쪽 region들을 언제부터 mark할 것이냐를 지정하는 옵션이다.
기본값 45는 region 크기(기본값 1MB)의 45%가 차면 mark를 시작한다는 뜻.
35를 지정하면 35%만 되어도 시작한다는 뜻이다.

이외에도 다른 정보들을 참고하면 다음 GC 쓰레드 갯수 관련 옵션들도 도움이 될 수 있다.

-XX:G1ConcRefinementThreads=20
-XX:ParallelGCThreads=20
-XX:ConcGCThreads=20 (이 옵션은 위에서 이미 언급)

주의할 점은 ConcGCThread 갯수를 늘리고 InitiatingHeapOccupancyPercent 비율을 줄이면 old region에 대한 concurrent gc를 자주 실행시켜 결국 full gc 즉, single-thread에 의해 처리되는 stop-the-world의 시간을 늦출 수 있다.
하지만 old region에 대해 쓰레드간 경쟁을 발생시켜 전반적으로 성능이 불안해지게 되는 문제가 있다.

stop-the-world 시간은 0.03초 정도인데 concurrent gc는 이를 회피하기 위해 매번 수행 시마다 수 분이 걸린다면 어느 게 더 나은 튜닝일까?

이것에 대한 선택은 좀더 고민해볼 필요가 있을 것이다.
기존 HotSpot JVM에서 Concurrent-Mark-&-Swap 방식을 사용할 것인가 Performance 우선 방식을 사용할 것인가 고민했던 것과 별반 다르지 않은 고민을 G1 GC 내부적으로 하게 되는 것 같다.

예전에 올렸던 아래 글 참고

G1 GC는 테스트해본 결과 별도의 파라미터를 지정하지 않더라도 상당히 효율적으로 메모리 관리를 하는 편이다. 반대로 힘들게 파라미터 튜닝을 해도 효과가 잘 드러나지 않는 편이기도 하다. ㅠ_ㅠ;

stop the world 시간이 짧으므로 주기적으로 idle time에 강제로 full gc를 실행하는 것도 서비스 품질을 유지하기 위해 필요한 정책이 아닐까 생각해볼 수 있다.
하지만, 강제로 full gc가 실행되는 걸 보장하려면 JVMTI를 사용하는 수밖에 없다.

G1 GC는 Old Generation GC를 꼭 필요할 때에만 실행한다. 보통 New Area와 Old Area 비율이 일정 값 이하로 떨어질 때 실행하게 된다. Young GC만 하다가 Old Area가 지속적으로 증가하여 New Area가 감소되면 Old Generation GC를 통해 어느 정도 회복을 한다.
물론 이 과정에서도 충분히 회복을 하지 못하면 결국엔 Full GC를 통해 회복을 하게 된다.

이 개념들을 잘 조합해서 G1 GC 튜닝을 이루기 바란다. 보통은 튜닝할 일이 없을 정도로 잘 동작하는 G1 GC이고 Region 개념상 효과적으로 큰 메모리를 적은 pause time으로 관리할 수 있지만 Full GC는 명시적으로 실행하거나 피하는 것이 최선이라고 할 수 있다.




참고 : G1 GC에서 실행하는 세 가지 유형의 collector 
자세한 내용은 위 오라클의 G1 GC 소개 페이지를 참조하면 된다.
간략하게 설명하면 다음 세 가지로 구성된다.
먼저 G1 GC에서 JVM Heap 영역은 1MB~32MB 이내의 고정된 크기로 2000여개 영역으로 분할되어 있다. 이 고정 크기 부분 영역을 Region이라고 부른다.
각 Region은 기존 JVM heap의 영역이었던 New Area(Eden Area), Survivor Area, Old Generation Area, Permant Generation Area를 각각 담당하지만, 동적으로 역할이 변경될 수 있다.
세 가지 유형의 Collector는 Young과 Old Generation별 GC와 Full GC이다.
  1. Young Generation GC
  2. Old Generation GC
  3. Full GC
1. Young Generation GC

Young GC는 하나의 단계로 구성된다.
-XX:ParallelGCThreads=8 과 같이 옵션을 통해 Young GC를 수행하는 thread 갯수를 조정할 수 있음. 대부분의 old generation GC의 copy나 cleanup 등 stop-the-world 방식 동작들(initial mark, remark, cleanup, copying, young)은 이 thread들이 piggyback하여 실행한다.
gc log에는 [GC pause (young)]으로 표시됨
  1. Young GC pause (Stop-the-world)
    • Young GC는 단계가 지나면 young generation region의 객체들을 survivor region들로 copy(move)
    • Survivor region의 오래된 객체는 old generation region으로 이동
2. Old Generation GC

Old GC는 다섯 단계로 구성된다.
대부분의 단계는 필요 시에 Young GC 실행 시에 piggyback되어 실행되므로 Young GC의 parallel gc thread들이 실행한다.
다만 시간이 많이 걸릴 수 있고 stop-the-world가 필요없는 mark 단계는 별도의 쓰레드를 통해 실행된다.
-XX:ConcGCThreads=8 와 같이 옵션을 통해 Old generation marking 단계에 사용되는 GC 쓰레드 갯수를 조정한다.
gc log에는 young GC에 piggyback되는 초기 mark 단계는 [GC pause (young) (initial-mark)]으로 표시되고, 마찬가지로 young GC에 piggyback되는 copy/cleanup 단계는 [GC pause (mixed)]로 표시된다.

  1. Initial Marking Phase (Stop-the-world)
    • Old GC가 필요해지면 Young GC 때 함께 실행
    • [GC pause (young) (initial-mark)]
  2. Concurrent Marking Phase
    • 빈 region들을 찾아 표기하고 region별 live object 비율을 계산해둔다.
    • 이 region들은 바로 다음 Remark 단계에서 제거
    • 별도의 concurrent GC thread들이 실행
  3. Remark Phase (Stop-the-world)
    • 빈 region들은 삭제해서 free로 만든다.
    • 전체 region들의 live object 비율이 계산된다.
  4. Copying/Cleanup Phase (Stop-the-world)
    • 가장 빨리 청소가 가능한 live object 비율이 낮은 region들을 선택한다.
    • Young GC 때 선택한 region들을 청소한다.
    • [GC pause (mixed)]
  5. After Copying/Cleanup Phase
    • 선택된 region들의 compaction이 완료된 시점.
    • young과 old generation이 모두 cleanup되고 선택된 region들은 모두 새로운 region으로 compaction되어 위치한다.

3. Full GC
G1 GC는 가능하면 Full GC를 회피하기 위해 여러 가지 Young GC와 Old GC를 적절한 시점에 실행한다.
Young GC는 일상적으로 실행되며, Old GC는 young area와 old area 비율이 일정 값 이하로 떨어졌을 때 (즉, young area가 부족하게 되었을 때) 트리거되어 실행된다.
예를 들어 기본값으로 young과 old는 1:2의 비율을 가지고 있다. 따라서 old area 비율이 늘어나서 young area의 2배를 가지게 되면 old generation gc가 실행된다.
만일 Old GC를 통해서도 필요한 young area를 확보하지 못하게 되면, 어쩔 수 없이 Full GC를 실행하게 된다.
  • Single-threaded
  • Stop-the-world
  • 이때 permanent area cleanup도 실행 (즉, classloader unloading은 이때 일어남)

참고 : G1GC에서 class unloading 관련한 이슈

Hot Deploy를 많이 할 경우 JDK 7 G1 GC에서는 perm generation 문제가 발생할 수 있다.




위 내용을 요약하면

  1.  JDK 7의 G1 GC는 class unloading을 full gc가 발생했을 시에만 수행하게 된다.
  2. 이 문제는 JDK 8u40 버전에서 permanent generation을 없애고 metaspace 방식으로 바꾼 후에 해결되었다.

JDK 8 G1 GC에서는 class 영역이 클 경우 class unloading을 하는 gc 시간이 매우 길어질 수 있는데 다음과 같이 JVM 옵션을 추가하면 대부분 해결된다는..

-XX:+UseLargePagesInMetaspace

JDK 8에서는 perm area가 아니라 metaspace에 class 정보들이 올라가는데 이때 그 영역이 크면 gc 시간이 오래 걸릴 수 있는데
이럴 때는 metaspace에 large page를 사용하여 접근하도록 JVM 옵션을 주면 대부분 문제가 해결될 수 있다는 것. (TLB 관련 이슈)



댓글

이 블로그의 인기 게시물

Heap Dump 분석을 통한 Perm Area Memory Leak 원인 진단

맥북프로 13인치 2010년 버전의 하드웨어 업그레이드 산전수전 경험기