jvm 옵션은 기본옵션을 유지하는 것이 좋다고 하여, 옵션을 안건드렸으나,

ehcache의 내부 메모리의 크기가 기하급수적으로 증가하는 로직이 하나가 추가되면서, 서버에 부하가 생기게 되었습니다.

서버 장애원인을 찾아보니,

ehcache가 잡아먹는 JVM 의 메모리에 의해, 강제 FULL GC가 발생하고, 그 발생한 부분의 지연현상때문에, 전체적인 서비스가 지연되는 문제였습니다.

java version 은 1.8 을 사용하고 있었는데,
JDK8 에서는 Default 로 ‘Parallel GC’ 를 사용합니다.

그래서, 결국 jvm 옵션을 건드릴 수 밖에 없었습니다.

-XX:+UseG1GC

G1 GC의 가장 큰 장점은 성능입니다.

JAVA_OPTS="-verbosegc -server -Xms6g -Xmx6g -XX:MaxGCPauseMillis=700 -XX:+PrintConcurrentLocks -Djava.security.egd=file:/dev/./urandom -Dscouter.config=/usr/local/tomcat7/conf/scouter.conf -Duser.timezone=GMT+09:00 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/tomcat7/logs/memory_err.log"

기존 옵션에서 ‘-XX:+UseG1GC’ 만 추가하였습니다.

JDK 8 부터 G1 이 안정적이 되었기에 많은 서비스들이 G1 GC 를 사용 중으로 알고 있습니다.
(JDK8 에서는 Default 로 ‘Parallel GC’ 를 사용하기 때문에 G1 GC를 사용하지 않습니다. )

‘Parallel Collector’ 는 Compaction 단계 때문에 G1 GC 보다 FGC (Full Gabage Collection) 시간이 오래 걸리며,
실제 제 서비스에서는 점점 GC시간이 늘어나는 상태였습니다.

JAVA_OPTS="-verbosegc -server -Xms9216m -Xmx9216m -XX:NewRatio=5  -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=75 -Djava.security.egd=file:/dev/./urandom -Dscouter.config=/usr/local/tomcat7/conf/scouter.conf -Duser.timezone=GMT+09:00 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/tomcat7/logs/memory_err.log"

현재 75% 로 GC가 강제로 찾을 경우 강제 GC를 떨어뜨니는 기능과 단순하게 G1GC 나머지는 디폴트값으로 설정하는 것과 비교할 예정이며, 현재로써는 G1GC 로 하는것이 개인적으로 관리할때는 편해보여, 상태를 보다가 전체 적용할 예정입니다.