개요

픽블엽의로그/지표를 보던 중 약 20초 동안 서버가 멈춘 듯한 현상을 발견했다. 원인을 확인해보니, GC(Garbage Collection) 과정에서 Stop The World(STW) 가 무려 20초 동안 발생한 것이었다...

문제 확인

위 지표를 보면, Old 영역에서 Major GC가 발생했는데 그 과정이 약 20초가 걸린 것을 확인할 수 있다.

원인 분석

아쉽게도 GC 로그를 남기지 않고 있었기 때문에 정확한 분석은 어려웠다.
하지만 20초라는 긴 STW는 비정상적이기에 원인을 추적해봤다.

분석 결과, GC 알고리즘이 SerialGC로 동작하고 있었다.

Java 21을 쓰고 있는데 왜 기본 GC가 G1GC가 아니라 SerialGC일까?”

원인은 서버 스펙(t2.micro) 때문이었다.
메모리가 적은 환경에서는 JVM이 기본적으로 SerialGC를 선택하는 경우가 있다고 한다.

문제 해결

✅ G1GC적용

서버 실행 시 GC를 직접 지정하여 G1GC를 강제하도록 설정했다.

JAVA_OPTS="
  -XX:+UseG1GC
  -Xms384m -Xmx384m
  -XX:MaxGCPauseMillis=200
  -XX:InitiatingHeapOccupancyPercent=30
  -XX:ParallelGCThreads=1
  -XX:ConcGCThreads=1
  -Xlog:gc*,safepoint,age=debug:file=$LOG_DIR/gc.log:time,uptime,level,tags:filecount=5,filesize=20m
"

ec2에서 서버를 띄울 때 GC를 직접 변수로 지정하여 G1GC로 띄우고 GC의 상한선을 두었다.

✅ GC 로그 기록

이전에는 GC 로그를 남기지 않았지만, 이번 기회에 GC 로그를 파일로 기록하도록 설정했다.
앞으로 문제가 발생했을 때 훨씬 빠르게 원인을 추적할 수 있을 것이다.

-Xlog:gc*,safepoint,age=debug:file=$LOG_DIR/gc.log:time,uptime,level,tags:filecount=5,filesize=20m

✅ GC 간단 비교

• SerialGC: 단일 스레드로 GC 작업을 처리 → 속도가 느리고, STW가 길어짐
• G1GC: 메모리를 여러 Region으로 분할하고, 필요한 부분만 빠르게 수거 → STW 시간이 획기적으로 줄어듦

결론

이번 장애는 GC 로그가 없어 정확한 원인을 파악하기 어려웠다.
하지만 SerialGC에서 G1GC로 전환하고, GC 로그를 기록하도록 개선하면서 앞으로는 긴 STW 현상을 줄이고 원인 분석도 용이하게 만들었다.

👉 교훈: “GC는 강제 설정하는게 좋고, GC 로그는 반드시 남겨라.”