개 요

GC를 어떻게 관리하느냐에따라 성능에 영향이 미친다.

GC수행 소요시간이 0.1~0.3초면 굳이 튜닝이 필요없다.

GC수행 소요시간이 1~3초, 10초가넘는 상황일경우 GC튜닝을 진행하여야한다.

GC수행 시에는 JVM이 멈추기때문에 사용자에게 아주큰불편함을 줄수있다.

 

GC 종류

- minor GC

- Full GC(major GC)

 

메모리와 GC의 관계

메모리크기가크면

- GC 발생횟수는줄어든다.

- GC 수행시간은길어진다.

 

메모리크기가작으면

- GC 수행시간은적어진다.

- GC 발생횟수는증가한다

 

New 영역의 크기가 작으면 Old 영역으로 넘어가는 메모리의 양이 많아져서 

Full GC도 잦아지고 시간도 오래 걸린다.

 

평균 YGC 수행시간 = YGCT/YGC

평균 FGC 수행시간 = FGCT/FGC

 

아래 조건을 만족한다면 더이상 GC 튜닝이 필요없다.

- Minor GC의처리시간이빠르다(50ms내외).

- Minor GC 주기가빈번하지않다(10초내외).

- Full GC의처리시간이빠르다(보통1초이내).

- Full GC 주기가빈번하지않다(10분에 1회).

 

GC 방식(알고리즘)

https://12bme.tistory.com/57

Serial Collector

: Young영역과 Old영역이 시리얼하게(연속적으로)처리 됨.

: 하나의 CPU를 사용.(적은메모리와 CPU코어 개수가 적을떄사용.)

: stop-the-world > 콜렉션이 수행될 때 어플리케이션 수행이 정지.

: Eden > From Survivor > To Survivor > Old 

: 일반적으로 클라이언트 종류의 장비로 사용.(대기시간이 많아도 크게 문제되지 않는시스템)

: Old영역 GC는 Mark-Sweep-Compact 콜렉션 알고리즘사용

 

Parallel Collector

: Young영역에서 콜렉션을 병렬로 처리함.

: 많은 CPU 사용으로 GC부하를 줄이고 어플리케이션의 처리량을 증가시킴.

: Old영역 GC는 Mark-Sweep-Compact 콜렉션 알고리즘사용

 

Parallel Compacting Collector

: Young영역에 대한 GC는 병렬콜렉터와 동일.

: Old영역 GC가 다름.

: 병렬콜렉터와 동일하게 이 방식도 여러 CPU사용하는 서버에 적합.

 

CMS(Concurrent Mark-Sweep) Collector

: low-latency collector

: 힙 메모리 영역의 크기가 클 때 적합.

: Young영역에 대한 GC는 병렬콜렉터와 동일.

: Old영역의 GC는 아래 단계를 거침.

1) Initial Mark단계 : 매우 짧은 대기 시간으로 살아있는 객체를 찾음.(멈추는시간매우짧다)

2) concurrent Mark단계 : 살아있는 객체에서 참고하고 있는 객체를 따라가며 확인.

(다른스레드가 실행 중인 상태에서 동시에 진행됨)

3) Remark단계 : concurrent mark 단계에서 표시하는 동안 변경된 객체에 대해서 다시표시 단계.

4) Concurrent Sweep 단계 : 표시되어있는 쓰레기를 정리하는단계.

: 이러한 단계로 실제 stop-the-world 시간이 매우 짧아, 모든애플리케이션의 응답속도가 중요할때 CMS GC를 사용.

: CMS 콜렉터 방식은 2개이상의 프로세서를 사용하는 서버에 적당.(가장적당대상 웹서버)

: 단점

1) CMS는 compact단계를 거치지 않아 왼쪽으로 메모리를 몰아놓는 작업수행하지않음.

2) 다른 GC방식보다 메모리와 CPU를 더 많이 사용한다.

: Permanent genalation 영역의 GC를 수행하지 않는다. 수행할경우 CMSClassUnloadingEnabled 옵션추가

 

G1 GC 

: GC 관리 방식

1) heap memory를 N개영역으로 나누어 각영역에대해 GC 실행.(바둑판형식)

(각 영역을 region이라는 블럭으로 불림.)

2) 그러다, 해당영역이 꽉 차면 다른영역에서 객체를 할당하고 GC 실행. 

3) Old영역이 GC되면 이영역을 young영역이 사용가능.

: 기존 메모리관리 모델들은 전체에 대해 Full GC일어나니 수행시간이 매우 길었지만,

G1 GC 경우 각 Region으로 GC가 되기때문에 수행시간이 매우짧음.

: CMS GC를 대체하기 위해 만들어짐.

: 가장 큰장점은 성능이다. 어떠한 GC방식보다도 빠르다.

: 하지만, JDK6에서 G1 GC를 적용했다가 JVM Crash가 발생했던 적도있어다고함. 아직 안정성 검증이 필요. JDK6에서는 시험삼아 사용할수있게 제공.

: JDK7에서는 정식으로 G1 GC를 포함하여 제공.

: java8 에서는 성능에 이점이 많다고한다. java8에서 기본설정되어있슴

: 단점

1) perm generation collection을 full gc 때만 하는 문제.

(자주 재배포 되는 환경 경우, 문제가 될수있음. jdk8에서는 perm을 없앴기 때문에 이상없음)

2) 큰객체들에 대한 처리가 최적화 되지않음. 

region 영역에 Humongous regions(거대객체)가 된경우 처리방법

3) old영역으로 넘어간 객체들의 컬랙션은 실행이 잘되지않음.

--XX : G1HeapRegionSize = n 

-XX : MaxGCPauseMillis = 200 

-XX : G1NewSizePercent = 5 

-XX : G1MaxNewSizePercent = 60 

-XX : ParallelGCThreads = n 

-XX : ConcGCThreads = n 

-XX : HeapOccupancyPercent = 45 시작

-XX : G1MixedGCLiveThresholdPercent = 65 

-XX : G1HeapWastePercent = 10 

-XX : G1MixedGCCountTarget = 8 

-XX : G1OldCSetRegionThresholdPercent = 10 

-XX : G1ReservePercent = 10

oracle공식 : https://www.oracle.com/technetwork/articles/java/g1gc-1984535.html

https://d2.naver.com/helloworld/1329

 

튜닝하기

서비스에 맞는 GC 알고리즘 선택

GC알고리즘 설정

성능테스트

Full GC 발생 빈도, 시간을 확인해가며 설정 최적화

 

결론

- 높은 성능을 요구한다면, G1 GC사용해야한다. 각 Region영역 별로 GC발생하기때문에 멈춤현상이 거의 없으면서 heap메모리를 높일 수있다.

- CMS와 Parallel GC 방식 차이는 Compaction 작업 진행여부다. CMS는 Compaction 작업을 하지않아 Full GC 수행시간이 짧다. 

하지만, Compaction을 수행하지않으면 여기저기 빈공간이 생겨 큰객체가 들어갈 공간이없어 Concurrent mode failure 라는 경고가 발생하면서 

Compaction 작업을 수행한다. 이때 Parallel GC방식보다 느리다.

 

참고자료

튜닝방법 https://d2.naver.com/helloworld/37111

G1 GC : https://mirinae312.github.io/develop/2018/06/04/jvm_gc.html

 

'서버 > 성능과 튜닝' 카테고리의 다른 글

톰켓(Tomcat) 성능 튜닝하기  (0) 2020.05.19
성능테스트 프로세스  (0) 2020.05.19
API 성능테스트 시 고려사항  (0) 2020.05.06
JVM 설정하기  (0) 2020.02.09
JVM(Java Virtual Machine) 역할 및 구조  (0) 2020.02.09

+ Recent posts