GC 튜닝

GC튜닝이 필요한 경우

JVM옵션 중

Xms 옵션과 Xmx 옵션으로 메모리 크기를 지정하지 않았다.

-Server 옵션이 포함되어있지 않다.

시스템에 Timeout 로그와 같은 로그가 남는다.

 

심플한 튜닝

1.String 객체 대신 StringBuilder 혹은 StringBuffer를 사용한다.

2.Log를 적게 쌓는다.

 

방법 첫번째 : Old영역으로 넘어가는 객체의 수 최소화 하기

New영역을 크기를 조정해서 혹은 Old영역과의 New 영역과의 비율을 조정해서 Old영역으로 넘어가는 객체 수를 줄여

Full GC가 일어나는 횟수를 줄여준다.

 

방법 두번째 : Full GC 시간을 줄이자

Full GC실행 시간은 Minor GC에 비해 길기 때문에 Old 영역의 크기를 잘 조정해서 Full GC 용량을 줄여준다. 

(물론 빈도 수 는 증가한다.) 그러나, 마음대로 막 줄이면 OutOfMemoryError가 발생하거나 FullGC 횟수가 너무

많아진다.

 

방법 세번째 : GC의 성능을 결정하는 옵션

이런저런 옵션을 막 추가하는것이 아니라, 두 대 이상의 옵션을 각기 다르게 줘서 어떤 옵션을 줬을 때

더 속도가 빠른지 확인하여 더 나은 옵션으로 적용한다.

 

구분	옵션	설명
힙영역크기	-Xms	JVM 시작시 힙 영역 크기
	-Xmx	최대 힙 영역 크기
New 영역의 크기	-XX:NewRatio	New 영역과 Old영역의 비율
	-XX:NewSize	New 영역의 크기
	-XX:SurvivorRatio	Eden영역과 Survivor 영역의 비율

이 중 자주 사용되는 옵션은 -Xms, -Xmx, -XX:NewRatio 옵션이다.

-Xms, -Xmx 는 거의 필수이며 NewRatio옵션을 어떻게 하느냐에 따라 GC성능 차이가 많이 발생한다.

 

Perm영역의 크기조정은 OutOfMemoryError가 발생하고, 그 문제의 원인이 Perm영역의 크기 일때만

-XX:PermSize, -XX:MaxPermSize옵션으로 지정한다.

 

GC 알고리즘을 선택 하는 옵션들

구분	옵션	비고
Serail GC	-XX:+UserSerailGC
ParallelGC	-XX:+UserParallelGC -XX:ParallelGCThreads=value
Parallel Compacting GC	-XX:+UseParallelOldGC
CMS GC	-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=value -XX:+UseCMSInitiatingOccupancyOnly
G1	-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

G1 GC를 제외하고는 각 GC방식의 첫번째 줄에 있는 옵션을 지정하면 GC방식이 결정된다.

 

GC 튜닝 절차

1. GC 모니터링 

 

2. 모니터링 결과 분석 후 GC 튜닝 여부 결정 :

GC수행 시간이 길때,

그러나 메모리를 크게 잡아놓고 메모리를 줄일 수 없다면 왜 그렇게 메모리를 크게 잡아야하는지 확인하고

메모리를 줄였을 때 OutOFMemoryError가 발생하면 힙덤프를 떠서 그원인을 확인하고 문제점을 제거한다.

 

힙덤프 - 현재 Java메모리에 어떤 객체와 어떤데이터가 있는지 확인하기 위한 메모리의 단면 파일이다.

             JDK에 포함되어있는 jmap명령으로 생성할 수 있고, 파일을 생성하는 도중에는 java프로세스가 

            멈추기 때문에 시스템 운영시에는 생성을 하면 안된다.

 

WAS의 GC상황을 잘 파악하기 위해 jstat명령어를 사용하여 YGC와 YGCT의 값을 확인한다. YGCT/YGC로 나누면

YOUNG 영역에서의 GC수행시간이 나온다. 또, FGCT 와 FGC로 같은 작업을 하면 Full GC 시간을 알 수 있다.

 

Minor GC의 처리시간이 (50ms내외), Minor GC의 주기가 빈번X(10초 내외)

Full GC의 처리시간이 빠르다 (1초내외) , Full GC주기가 빈번하지 않다 (10분 1회)

이조건을 만족하면 GC튜닝이 거의 필요없지만

서비스에따라서 GC처리시간에 대한 기준에 맞춰서 GC튜닝을 해본다.

문제는 처리시간만 보는게 아니라 빈도수도 봐야한다는것이다. 처리시간이 아무리 빨라도 계속 GC가 일어나면

Stop The World가 계속 일어나게 된다.

 

 

3. GC 방식 / 메모리 크기 지정

이것에는 사실상 정답이 없다. 서비스 규모에 따라 다르고 서버의 성능에 따라 다르다.

따라서 가장 좋은 방법은 같은 서버를 여러개 준비하여 테스트 비교분석하여 적합한 옵션을 선택하는 것이다.

메모리 같은 경우 FullGC 후 남아있는 메모리 (기본 사용) + Old영역용 메모리 + 여유메모리로 지정하는 것이

좋다.  이역시 비교 테스트 후 고르는 것이 좋다. 그리고 -XX:NewRatio=1 => New영역:Old영역이 1:1이다.

-XX:NewRatio=2 New영역:Old영역이 1:2이다. Old영역 비율이 커지면 GC가 적게 일어나나 속도가 느려진다.

전반적으로 NewRatio값이 2나 3일때의 GC상황이 좋을 수가 있다.

 

4. 결과 분석 - 결과를 24시간 지켜본 후 데이터 수집 후 비교하여 적절한 옵션을 선택한다.

FullGC 수행시간, Minor GC수행시간 ,Full GC 수행 간격 , Minor GC 수행간격

전체 Full GC 수행시간, 전체 Minor GC수행시간, 전체 GC수행시간 ,Full GC 수행 횟수 ,Minor GC 수행횟수

가장 큰 비중을 차지하는 것은 Full GC 수행시간 ,수행간격 수행 횟수 등이다.