JVM heap은 멀쩡한데 왜 메모리가 터질까? — Docker 네이티브 메모리 삽질기 Part 1

JVM의 -Xmx 설정으로 heap을 8GB로 제한했음에도 Docker 컨테이너가 OOM으로 강제 종료되는 상황이 발생했다. 실제 프로세스 메모리(RSS)가 14GB에 달하는데 heap은 멀쩡했다는 게 핵심 수수께끼다. JVM 메모리가 heap과 native 메모리 두 구성요소로 이뤄져 있으며, cgroup은 전체 RSS를 기준으로 OOM을 판단한다는 사실이 이 미스터리의 열쇠다.

핵심 포인트

JVM 메모리는 GC가 관리하는 heap과 malloc으로 할당되는 native 메모리 두 영역으로 구성된다.
-Xmx8G는 heap만 제한하며, native 메모리 사용량은 무관하게 증가할 수 있다.
Docker cgroup은 JVM heap이 아닌 전체 프로세스 RSS를 기준으로 메모리 제한을 적용한다.
cgroup이 보는 RSS가 설정 한도를 초과하는 순간 Linux OOM Killer가 컨테이너를 강제 종료한다.
heap 모니터링 도구만으로는 이 문제를 발견할 수 없으며, native 메모리를 별도로 추적해야 한다.

상세 정리

현상: -Xmx8G로 heap을 8GB 제한했음에도 Docker 컨테이너가 OOM으로 사망.
측정 격차: JVM이 보고하는 heap 사용량은 정상 범위인데 실제 프로세스 RSS는 14GB — 약 5GB의 설명되지 않는 메모리 소비 존재.
OOM 발생 메커니즘: cgroup이 RSS 기준으로 메모리 한도를 감시. RSS가 설정 한도를 넘으면 Linux OOM Killer가 컨테이너 프로세스를 즉시 종료. "cgroup이 보는 RSS가 한도를 넘자 리눅스 OOM Killer가 컨테이너를 그냥 죽인 겁니다."
JVM 메모리 구성: heap(Eden/Survivor/Old/Metaspace 포함, -Xmx로 제한), native 메모리(JIT 컴파일, 클래스 로딩, JNI, 스레드 스택, 직접 버퍼, OS 라이브러리 등 malloc 사용).
모니터링 맹점: JVM GC 모니터링 도구, Heap Dump, VisualVM 등은 heap 영역만 추적. Native 메모리는 표준 JVM 모니터링에서 보이지 않음.
Docker 환경 특수성: 베어메탈 환경에서는 OS가 스왑 등으로 메모리 압박을 흡수하지만 Docker cgroup은 즉각적인 하드 한도를 적용해 여유 없이 종료.
문제의 심각성: heap만 관리한다고 생각했는데 native 메모리가 예측 불가능하게 성장해 컨테이너가 반복 재시작되는 운영 장애로 이어짐.
다음 단계(Part 2 예고): NMT(Native Memory Tracking), jemalloc/jeprof, async-profiler 등 전문 도구로 native 메모리 5GB의 실제 원인을 추적하는 디버깅 과정.