기본 콘텐츠로 건너뛰기

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 원인 진단

Software 특히 Java 언어를 사용하는 Software 개발 조직에 몸담고 있지만, 마흔을 훌쩍 넘긴 나이에 이런 글을 쓰는 것이 적합한지 의심되는데 특히 국내 SW 환경을 고려한다면 몹시 우스꽝스럽다.

이젠 개발팀장도 아니고 개발실장도 아니고 그위의 관리자이지만, 아직 완전히 제품 코드로부터 역할을 분리하지 못했고, 이러한 시간이 많이 걸리고 책임 소재가 불분명한 문제를 해결할 전문 인력을 두고 있지 않기 때문에 결국 직접 하는 경우가 생긴다. 이것은 미흡한 관리 능력의 결과라고 봐도 좋겠다.

개인적으로는 이러한 일이 전혀 나쁘지 않다. 즐거운 Software Life의 하나일 뿐이다.
관리자가 이러한 삽질을 직접 하는 것이 관리 체계를 무너뜨리는 것 아니냐고 묻겠지만...

oh, give me a break.. 나중에 교육교재 만드는 데 도움이 될까해서 하는 관리 행위의 하나라고 봐주기 바람~~ ㅠ_ㅠ;;

perm gen 과 class leak
Permanent Generation 은 young과 old를 구분하는 Generational Collector 방식인 Sun (now, Oracle)의 HotSpot JVM에서 Old generation 중 한 영역이다.
lifetime이 길다고 판단된 object들을 old generation으로 옮겨서 빈번한 gc의 대상이 되지 않도록 하는 것이 generational collector의 기본 아이디어인데 permanent generation은 old 중에서도 거의 gc 대상이 될 일이 없다고 생각되는 object들을 딴 영역에서 관리하겠다는 아이디어의 산물이다.

HotSpot JVM의 Perm Area 에는 주로 자바의 클래스 객체들이나 문자열 상수 풀에 속한 String 객체들이 위치한다.
메모리 leak의 대상이 되는 것은 string constants 보다는 주로 class 객체들이다.

(class 객체는 주로 객체의 타입을 나타내는 클래스나 인터페이스를 표현하는 객체로 타입명 뒤에 .class…

더 재미있게 사는 10 가지 간단한 방법

How To Be More Interesting (In 10 Simple Steps) - Forbes

어떻게 하면 좀더 재미있게 살 수 있을까?

Software를 얼마나 재미있게 할 수 있을까?

늘 갖고 있는 생각인데 저는 대부분 매우 재미를 가지고 일을 하는 편입니다.
새로운 것을 알게 되는 것이 매우 즐겁고 여러 사람들과 토론 속에서 문제를 해결해가는 과정은 때론 신비롭기도 하고 놀랍기도 합니다. 그 놀라움의 대상은 뛰어난 아이디어를 내는 다른 연구원일수도 있고 문제를 여러 토론 속에서 얼떨결에 해결해내고 있는 자신일수도 있습니다.

개인과 소규모 그룹, 그리고 그보다 더 큰 그룹을 유기적으로 연결하여 혁신 아이디어 체계를 구축하는 일이 현재의 본업이라고 생각하는데 그 출발점은 각 성원들이 흥미를 가지고 자신의 일과 관심 속에서 아이디어를 만들고 공유하고 또 발전시키는 것이라고 생각합니다.

재미있게 일하는 것은 여러 가지 아이디어를 적극적으로 매사에 적용해보는 것이 아닐까 생각해봅니다. 또 일을 하는 것이 아니라 늘 같지 않은 일로 만들 수 있는 적극성이 필요한 것이지요. 다행히 제 일인 소프트웨어는 늘 아이디어를 필요로 하고 아이디어에 따라 크게 달라집니다.

이 글은 벤다이어그램이나 그래프로 표현한 것이 재미있어서 옮겨봅니다.

1. 탐험하라. 아이디어, 장소, 의견을 탐험하라. 에코 체임버 안에 모든 지루한 사람들은 갇혀 있다. (해야 할 일과 가야할 곳이 만나는 곳이 무한의 영역이라는 표현 재미있습니다.)






2. 발견한 것을 공유하라. 발견한 것을 인심좋게 공유하라. 모든 사람이 당신의 탐험을 함께 하지 않았다. 다른 사람들이 당신의 탐험, 모험을 대리경험할 수 있도록 하라. (발견을 공유하지 않으면 발견이 많더라도 dumb 벙어리일 뿐이고 발견이 많고 이를 공유를 많이 하는 사람이 smart하다는 것. 공유하는 과정에서 더 발견이 많아지고 깨달음도 커지고 당연히 smart해지겠지요)





3. 무언가를 하라. 무엇이든 하라. 춤추고, 얘기하고, 만들고, 사람들을 …