티스토리 뷰
본 포스팅에서는 주요 GC 알고리즘과 JVM 튜닝을 위한 여러가지 옵션에 대해 알아보겠습니다.
Java별 제공하고있는 다양한 GC 방식과, 튜닝에 필요한 여러 JVM옵션에 대해 살펴보겠습니다.
1.IBM JVM
optthruput GC | |
옵션 |
-Xgcpolicy:optthuput |
설명 |
default GC 알고리즘. GC작동시 mark-sweep-compact단계를 수행하며 STW로 일시정지됨. application이 복잡해지고 그에 따라 heap이 커지면 GC수행에 따른 멈춤시간도 증가하게됨 |
장점 |
Throughput이 향상 |
단점 |
STW로 인한 response time이 감소 |
optavgpause GC | |
옵션 |
-Xgcpolicy:optavgpause |
설명 |
optthuput 단점인 STW시간을 보완하고자 함. GC를 위한 thread를 추가적으로 만들어서 concurrent mark 를 수행하게 하여 실제 GC가 발생할때 전체 heap 영역에 대한 mark 작업을 수행할 필요없이 sweep단계를 수행할수 있도록 함. |
장점 |
전반적인 response time이 향상된다 |
단점 |
Throughput이 감소 |
* optthruput GC와 optavgpause GC의 장단점으로 확인하였을때, Throughput(처리량)과 response time은 반비례관계에 있다는것을 알수 있습니다.
gencon GC | |
옵션 |
-Xgcpolicy:gencon |
설명 |
Sun JVM과 동일한 구조이며,response time과 throughput를 모두 향상시킬 수 있는 방식으로, Heap을‘Nursery Space’와 ‘Tenured Space’으로 구성하며,‘Nursery Space’내에 다시 ‘Allocate Space’와 ‘Survivor Space'로 나누어진다. Nursery Space의 gc 는 minor gc로, Copy 방식(Alive Object를 Allocate Space에서 Survivor Space로 복사하는 것을 의미)을 사용하며, Tenured space의 gc는 Full gc로 Mark+Sweep+Compaction이 수행된다. |
장점 |
response time과 throughput의 동시에 향상된다.단 튜닝이 필요할 수 있다. |
단점 |
CPU 오버헤드가 발생한다. |
subpool GC | |
옵션 |
-Xgcpolicy:subpool |
설명 |
Java Heap을 여러 개의 Sub Pool로 나누어 관리하는 기법을 사용한다. 16 CPU 이상의 서버 환경에서만 사용할 것을 권장한다.Sun JVM의 Parallel GC와 동일한 방식이다. |
2.Sun HotSpot JVM
Serial GC | |
옵션 |
-XX:+UseSerialGC |
설명 |
Serial GC는 적은 메모리와 CPU 코어 개수가 적을 때 적합한 방식이며, 단일 Thread가 GC를 수행한다. |
Parallel GC | |
옵션 |
-XX:+UseParallelGC |
설명 |
Parallel GC는 Serial GC와 기본적인 알고리즘은 같다. 그러나 Serial GC는 GC를 처리하는 thread가 하나인 것에 비해, Parallel GC는 GC를 처리하는 thread가 여러 개이다. 따라서 Serial GC보다 빠른게 객체를 처리할 수 있다. Parallel GC는 메모리가 충분하고 코어의 개수가 많을 때 유리하다. |
Parallel Old GC | |
옵션 |
-XX:+UseParallelOldGC |
설명 |
Parallel GC와 비교하여 Old 영역의 GC 알고리즘만 다르다. Mark-Summary-Compaction 단계를 거친다. Summary 단계는 앞서 GC를 수행한 영역에 대해서 별도로 살아 있는 객체를 식별한다는 점에서 Mark-Sweep-Compaction 알고리즘의 Sweep 단계와 다르다. |
CMS GC | |
옵션 |
-XX:+UseConcMarkSweepGC |
설명 |
initial Mark>Concurrent Mark>Remark<Concurrent Sweep 방식으로 진행하며, Concurrent Mark,Concurrent Sweep의 경우 다른 Thread가 실행중인 상태에서 동시에 진행된다. 따라서 STW시간이 짧다. 모든 Application의 response time이 중요할때 사용하며, 대신 메모리와 CPU를 많이 사용한다. 기본적으로 Compaction작업이 제공되지않는다. |
G1GC | |
옵션 |
-XX:+UseG1GC |
설명 |
기존 JVM메모리 구조와는 다르게, Heap 영역이 1MB~32MB이내의 고정된 크기로 2000여개 영역으로 분할되어있다. 이 고정 크기 부분의 영역을 Region이라고 부른다. 각 Region은 기존 JVM heap 영역이었던 New,Survivor,Old,Perm 영역을 각각 담당하지만, 동적으로 역할이 변경될 수 있다. Region 안에 있는 객체들이, 다른 Region에 있는 객체들에 의해서 참조되는지를 관리하고, Region단위로 Live Object가 있는지 없는지를 판단하여 해당 Region이 다 차면, 살아있는 Object들을 다른 Region으로 copy한후, 해당 Region을 비우는 작업을 한다. |
3.JVM튜닝을 위한 주요 옵션
3-1.IBM JVM
옵션 설명 -Xms JVM시작시 heap size -Xmx 최대 heap size -Xmn,-Xmns,-Xmnx New영역의 크기(최소=최대,최소,최대) -Xmo,-Xmos,-Xmox Old영역의 크기(최소=최대,최소,최대)
-Xdisableexplicitgc
System.gc()에 의한 GC를 비활성화한다.
-Xgcthreads
Parallel GC 작업을 할 Thread 개수를 지정한다. 만일 여러 프로세스가 CPU를 나누어 쓰는 환경이라면 이 값을 낮출 필요가 있다.
-Xloa
LOA(Large Object Area)를 사용할 지의 여부를 결정한다. Default는 활성화상태다. large object area는 Heap size의 5%를 차지하는데, AP의 특성상 비교적 큰 객체(5MB이상)의 생성이 빈번한 경우에는 이 영역을 늘려줄 필요가 있다.
-Xloainitial, -Xloamaximum, -Xloaminium
LOA의 초기 크기, 최대크기, 최소 크기를 지정한다. 0 ~ 1 사이의 값을 지정한다.
-Xmaxe, -Xmine
Heap expansion이 증가할 최대/최소 크기를 지정한다.
-Xmaxf, -Xminf
Heap 크기를 조정할 Free Memory의 비율을 결정한다. Default 값은 0.6(60%), 0.3(30%)이다. 즉, Free Memory가 전체 Memory의 60%이상이 되면 Heap Shrinkage가 발생하고, 전체 Memory의 30% 이하이면 Heap Expansion이 발생한다.
3-2.Sun HotSpot JVM
옵션 |
설명 |
-Xms |
JVM시작시 heap size |
-Xmx |
최대 heap size |
-XX:NewRatio |
New영역과 Old영역의 비율 |
-XX:NewSize |
New영역의 크기 |
-XX:MaxNewSiz |
New generation 의 heap size 최대값을 설 |
-XX:SurvivorRatio |
Eden영역과 Survivor영역의 비율 |
-Xcompactgc |
모든 garbage collections(system 또는 global)에 대하여 압축을 가능하게 한다. |
-Xnocompactexplicitgc |
System.gc() 호출에 의한 압축을 불가능하게 한다. 압축은 만약 –Xcompactgc 명시하거나 또는 compaction triggers를 만나면 global garbage collections 에서 발생한다. |
-Xcompactexplicitgc |
System.gc()가 호출 될 때마다 모든 GC 시스템에서 압축을 사용 가능하게 한다. |
-Xnocompactgc |
모든 garbage collections(system 또는 global) 에 대하여 압축을 사용 불가능하게 한다. |
-Xnoclassgc |
Class garbage collection 을 비활성화 한다. JVM에 의해서 더 이상 사용되지 않는 Java class 들과 연관된 storage의 garbage collection을 끈다. 즉 dynamic 클래스 로드 해제를 사용 불가능하게 한다. |
전체 Garbage Collection 을 할 때 시간이 3-4초 이상 걸리는 경우에는 Size 를 줄일 필요성이 있습니다.또한 Garbage Collection 이 끝난후에 Heap 에 할당된 메모리가 항상 85 % 이상이 되는 경우에도 size를 줄이는 것이 바람직합니다.
고맙습니다.
'② 성능 최적화, 트러블 슈팅 > ⓟ Performance Tuning' 카테고리의 다른 글
[GC Policy] GC 별 권고 옵션 자료 (G1GC, CMS, ParallelGC) (2) | 2019.01.09 |
---|---|
[GC] GC 잘하는법 (GC 알고리즘, GC 분석) (0) | 2018.11.08 |
[GC] Log 수집 및 분석 가이드 (0) | 2018.07.13 |
[GC] Log 분석 가이드 (IBM 계열 JDK) (0) | 2018.07.13 |
[GC] Log 분석 가이드 (HotSpot 계열 JDK) (0) | 2018.07.13 |
- Total
- Today
- Yesterday
- 마이크로서비스 아키텍처
- TA
- webtob
- node.js
- git
- JEUS7
- k8s
- Docker
- kubernetes
- Da
- JEUS6
- nodejs
- SA
- SWA
- openstack tenant
- 아키텍처
- API Gateway
- aa
- OpenStack
- 쿠버네티스
- 마이크로서비스
- apache
- Architecture
- MSA
- wildfly
- jeus
- aws
- 오픈스택
- JBoss
- openstack token issue
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |