[Infra Ops] Heap/GC/Thread Dump 분석과 OOM 대응 실무

OOM(OutOfMemoryError)이 발생했을 때 단순히 Heap 크기를 늘리는 것은 잘못된 방향일 수 있습니다. OOM은 Heap이 아닌 Metaspace 고갈이나 네이티브 메모리 부족에서도 똑같이 발생하며, 원인 영역을 잘못 짚으면 같은 장애가 반복됩니다. JVM이 메모리를 어떤 영역으로 나누고 각 영역이 무엇을 담는지 이해해야 에러 메시지만 보고도 어느 JVM 옵션을 조정해야 할지 판단할 수 있습니다.

확대

OOM이 났을 때 "힙을 늘리면 되지 않나요?"라고 생각하기 쉽습니다. 하지만 OOM은 힙이 아닌 Metaspace에서도, 네이티브 메모리에서도 발생합니다. 영역별로 무엇이 쌓이는지 알아야 올바른 옵션을 고칠 수 있습니다.

Heap — 가장 큰 영역, GC 대상

확대

Metaspace (Java 8+, 구버전의 PermGen 대체)

클래스 메타데이터(클래스 구조, 메서드 바이트코드, static 변수 등)가 저장됩니다. 네이티브 메모리를 사용하며 기본적으로 크기 제한이 없어 무한정 증가할 수 있습니다. 클래스 누수(클래스로더 반복 생성)가 있으면 이 영역에서 OOM이 납니다.

# Metaspace OOM 메시지
java.lang.OutOfMemoryError: Metaspace

Stack — 스레드별로 존재

각 스레드가 독립적으로 소유합니다. 메서드 호출 정보(로컬 변수, 호출 스택)가 쌓입니다. 재귀 호출이 너무 깊으면 StackOverflowError가 납니다.

Native Memory

JVM 자체와 GC 스레드, JNI(네이티브 라이브러리) 등이 사용하는 OS 메모리입니다. java.lang.OutOfMemoryError: Unable to create new native thread가 이 영역 고갈의 신호입니다.

코드에서 new Order() 한 줄이면 객체가 생깁니다. 그런데 그 객체는 어디에 놓이고, 언제 사라지며, 왜 어떤 객체는 오래 살아남아 Full GC를 유발할까요? 객체의 일생은 Eden 할당 → Minor GC → Survivor 승격 → Old 승격 → Full GC → 회수 또는 OOM의 순서를 따릅니다. 이 흐름을 알면 jstat의 숫자(O·FGC)가 무슨 뜻인지, 왜 응답이 주기적으로 멈추는지, OOM 메시지가 어느 영역을 가리키는지를 단계로 읽어낼 수 있습니다.

[객체 생성]  new Order()
   │
   ① Eden에 할당                            (Young Generation, 빠른 bump 할당)
   │
   ② Eden 꽉 참 → Minor GC (STW 짧음)        (살아있는 객체만 Survivor로 복사)
   │
   ③ Survivor S0 ⇄ S1 이동, age +1           (Minor GC마다 생존하면 나이 증가)
   │
   ④ age 임계치 초과 → Old로 승격             (MaxTenuringThreshold, 기본 15)
   │    → 오래 사는 객체(캐시·세션)가 Old에 쌓임
   │
   ⑤ Old 꽉 참 → Major/Full GC (STW 김)       (Old 전체 정리, 전 스레드 정지)
   │
   ⑥ 회수 성공 → 공간 확보 / 실패 → OOM
   ▼
[결과]  회수되면 지속, 못 하면  java.lang.OutOfMemoryError: Java heap space

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 OOM 메시지가 어느 단계·어느 영역이 터졌는지를 알려줍니다. java.lang.OutOfMemoryError: Java heap space는 ⑥에서 힙 회수 실패(객체 누수 또는 힙 부족), : Metaspace는 힙이 아니라 클래스 메타데이터 영역(⑤⑥와 별개 영역, 보통 클래스로더 누수), GC overhead limit exceeded는 ⑤가 계속 도는데 ⑥ 회수량이 거의 없는 상태입니다. 그래서 진단의 출발점은 jstat -gcutil로 O가 Full GC(FGC) 뒤에도 줄지 않는지 보는 것이고, 줄지 않으면 힙 덤프로 ④에서 계속 승격되는 객체가 무엇인지 추적합니다. Full GC가 잦다는 것은 곧 힙 부족·누수의 신호입니다.

배포 직후부터 응답이 주기적으로 3~5초씩 멈추는 현상이 보고됩니다. 에러는 없고, 로그도 정상인데 간헐적으로 느립니다. GC 로그를 보니 Full GC가 30초마다 발생하고 있습니다. Java 8에서 기본 GC(Parallel GC)를 그대로 쓰는 4GB 힙 서버에서 자주 나타나는 패턴입니다. GC 종류를 이해하고 올바른 것을 선택해야 이 문제가 사라집니다.

GC는 "어떤 알고리즘으로 힙을 청소하느냐"의 차이입니다. 처리량(Throughput)과 응답 지연(Latency) 사이의 트레이드오프입니다. 운영 환경에 맞는 GC를 선택하지 않으면 주기적인 응답 지연이 발생합니다.

STW(Stop-The-World): GC가 실행되는 동안 모든 애플리케이션 스레드가 멈추는 현상입니다. 이 시간이 길수록 응답 지연이 발생합니다.

실무 선택 기준 — Tomcat 웹 서비스 기준:

힙 < 4GB, Java 8:  Parallel GC (기본값)
힙 >= 4GB, Java 8: -XX:+UseG1GC 명시적 지정
Java 9+:           G1GC (기본, 별도 옵션 불필요)
Java 15+, 초저지연: -XX:+UseZGC

OOM 알람을 받고 Tomcat을 재시작했는데, 힙 덤프가 남아있지 않습니다. "HeapDumpOnOutOfMemoryError 옵션을 설정했었나요?" — 아무도 모릅니다. 현장에서 이런 상황은 생각보다 자주 발생합니다. setenv.sh 하나만 제대로 관리하면 이런 상황을 예방할 수 있습니다. JVM 옵션이 어디에 있는지 모른다는 것 자체가 운영 리스크입니다.

JVM 옵션은 Tomcat 시작 스크립트에 환경변수로 넣습니다. /opt/tomcat/bin/setenv.sh 파일이 없으면 새로 만듭니다. CATALINA_OPTS에 추가하면 Tomcat 프로세스에만 적용됩니다.

# /opt/tomcat/bin/setenv.sh

export CATALINA_OPTS="
  -Xms2g
  -Xmx2g
  -XX:MetaspaceSize=256m
  -XX:MaxMetaspaceSize=512m
  -XX:+UseG1GC
  -XX:MaxGCPauseMillis=200
  -XX:+HeapDumpOnOutOfMemoryError
  -XX:HeapDumpPath=/tmp/jvm-dumps/
  -Xlog:gc*:file=/logs/gc.log:time,uptime:filecount=5,filesize=20m
  -Dfile.encoding=UTF-8
  -Duser.timezone=Asia/Seoul
"

옵션별 의미:

확대

"OOM이 나서 재시작했습니다. 원인을 모르겠습니다." — 이 말이 3번 반복되면 팀장이 묻습니다. "힙 덤프는 남겼습니까?" OOM은 발생 순간 증거를 남기지 않으면 사후 분석이 불가능합니다. 프로세스가 죽기 전 힙 전체를 파일로 떠두는 것이 힙 덤프입니다. 이 파일 하나가 "무엇이 메모리를 먹었는가"를 밝혀주는 유일한 단서가 됩니다.

힙 덤프는 특정 시점 힙 전체를 파일로 복사합니다. OOM의 원인 객체를 찾는 데 사용합니다. 파일 크기가 힙 크기와 비슷하므로(2GB 힙 → 2GB 파일) 디스크 여유를 미리 확인해야 합니다. 힙 덤프 생성 중 JVM은 잠깐 멈춥니다.

# 실행 중인 프로세스에서 힙 덤프 수동 생성
jmap -dump:format=b,file=/tmp/jvm-dumps/heap_$(date +%Y%m%d_%H%M%S).hprof PID

# OOM 발생 시 자동 생성 (setenv.sh에 미리 추가)
# -XX:+HeapDumpOnOutOfMemoryError
# -XX:HeapDumpPath=/tmp/jvm-dumps/

# 힙 덤프 파일 크기 및 생성 확인
ls -lh /tmp/jvm-dumps/*.hprof

분석 도구:

지금까지의 OOM 대응은 모두 '자바가 OutOfMemoryError를 던지고 힙 덤프를 남긴다'를 전제로 합니다. 그런데 컨테이너/쿠버네티스에서 도는 JVM은 힙 덤프 한 장 없이 조용히 죽는 방식이 따로 있습니다.

• 프로세스 RSS는 -Xmx가 아닙니다: JVM이 실제 점유하는 물리 메모리(RSS)는 힙(-Xmx)뿐 아니라 Metaspace, 스레드마다의 스택(스레드 수 × -Xss), 다이렉트 버퍼(off-heap), GC·JIT 자료구조, 코드 캐시의 합입니다. -Xmx2g여도 RSS는 2.5~3g가 되기 쉽습니다. 컨테이너 메모리 한도를 -Xmx와 똑같이 잡으면 off-heap이 한도를 밀어냅니다.
• JVM은 컨테이너 한도를 알아야 합니다: Java 8 초기 버전(u191 이전)이나 UseContainerSupport가 꺼진 JVM은 /proc/meminfo로 호스트 전체 RAM을 봅니다. 기본 힙을 호스트 RAM의 1/4로 잡으므로, 64g 호스트의 512m 컨테이너에서 힙을 16g로 산정하려다 곧바로 한도를 넘습니다. 요즘 JVM은 UseContainerSupport(u191+ 기본 on)로 cgroup 한도를 읽고, 힙은 -XX:MaxRAMPercentage로 한도의 비율로 지정합니다.
• OOMKill과 OutOfMemoryError는 다릅니다: 힙이 -Xmx에 닿아 JVM이 던지는 OutOfMemoryError는 자바 예외라 로그와 힙 덤프가 남습니다. 반면 프로세스 RSS가 cgroup 한도를 넘으면 커널 OOM killer가 SIGKILL로 즉시 죽입니다 — 컨테이너는 exit code 137(128+9)로 끝나고, 이건 자바 밖의 일이라 자바 OOM 로그도 힙 덤프도 없습니다. 그냥 파드가 재시작됩니다.

핵심 설계: 컨테이너에서는 (1) UseContainerSupport를 유지하고(구형 JVM이면 업그레이드), (2) -XX:MaxRAMPercentage나 -Xmx로 힙을 한도의 50~75%만 잡아 off-heap 여유를 남기며, (3) 죽었을 때 자바 OOM 로그가 아니라 커널 로그(dmesg)와 컨테이너 exit code(137)로 OOMKill 여부를 먼저 가립니다.