이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
Heap Dump와 메모리 장애 대응에서 붙잡아야 할 핵심 판단 기준은 무엇인가?dump는 증거이자 부하 작업이다라는 기준은 어떤 JVM/OS 신호로 확인되는가?- Java/Spring 코드에서
Heap Dump와 메모리 장애 대응판단 기준은 어떤 장애 신호로 드러나는가?
개요
이 문서의 주제는 Heap Dump와 메모리 장애 대응이다. Heap dump 수집, 보관, 분석, 운영 중 위험을 정리한다.
먼저 붙잡을 기준은 다음 문장이다. dump는 증거이자 부하 작업이다. 이 문서는 이 기준을 Java/Spring 실행 흐름, JVM/OS 관찰 지표, 장애 판단 순서로 연결한다.
핵심 모델
- 판단 기준: heap dump는 강한 증거지만 운영 비용도 큰 증거다.
- Heap dump는 live object graph를 보여 주지만 파일 크기, 민감 정보, 수집 부하를 고려해야 한다.
- Class histogram은 dump보다 가볍게 객체 분포를 먼저 볼 수 있는 출발점이다.
- Dump는 OOM 직전이나 leak 재현 시점처럼 의미 있는 시각에 남겨야 한다.
- Dump 분석은 큰 객체 하나보다 dominator, retained size, reference path를 본다.
문서별 핵심 구분
- heap dump는 객체 참조 관계를 보는 강한 증거다.
- dump 수집은 disk, I/O, 개인정보 노출 위험을 가진다.
- class histogram은 dump 전 가벼운 1차 증거가 될 수 있다.
원리
Heap dump는 특정 시점의 heap 객체와 참조 관계를 파일로 남긴 증거다. 어떤 객체가 많이 남아 있는지, 누가 참조하고 있는지 확인할 수 있어 heap leak 분석에 강하다.
하지만 dump 수집은 공짜가 아니다. 파일이 매우 크고, 수집 중 애플리케이션이 멈추거나 disk I/O가 커질 수 있으며, dump 안에는 개인정보, 토큰, 요청 payload가 포함될 수 있다.
장애 중에는 heap dump 전에 더 가벼운 증거를 먼저 볼 수 있다. OOM 메시지, GC log, jcmd GC.heap_info, class histogram, RSS 추세로 dump가 필요한지 판단한다.
Heap Dump와 메모리 장애 대응 관점에서 중요한 점은 “증거 가치”와 “운영 위험”을 같이 보는 것이다. dump를 남길 위치, 남길 시점, 보관 권한, 삭제 정책을 정하지 않으면 분석 도구가 새로운 장애 원인이 된다.
Java/Spring 연결
- Heap dump에는 request data, token, 개인정보가 들어갈 수 있어 접근 권한과 보관 기간이 필요하다.
- Spring cache, session, ThreadLocal, static map은 retained path에서 자주 확인한다.
- 운영에서는
jcmd GC.class_histogram으로 후보를 좁히고 dump 수집 여부를 결정한다. - Dump 저장 위치가 같은 disk라면 장애 중 disk pressure를 키울 수 있다.
- Heap dump 분석 결과는 코드의 참조 유지 경로와 cache eviction 정책으로 연결해야 한다.
코드와 설정 예시
jcmd <pid> GC.class_histogram > histogram-$(date +%Y%m%d-%H%M%S).txt
jcmd <pid> GC.heap_dump /data/dumps/heap-$(date +%Y%m%d-%H%M%S).hprof
chmod 600 /data/dumps/*.hprof예시는 dump 자체보다 수집 절차를 보여 준다. 먼저 histogram으로 후보를 좁히고, dump 위치의 여유 공간과 접근 권한을 확인한 뒤 민감 정보 보호를 적용해야 한다.
관찰 명령
jcmd <pid> GC.heap_dump /tmp/heap.hprof
ls -lh /tmp/heap.hprof
jcmd <pid> GC.class_histogram > histogram.txtHeap Dump와 메모리 장애 대응 관찰 명령은 결론이 아니라 가설 확인 도구다. 운영 중에는 반복 간격, 대상 PID, 수집 시각을 함께 남기고 출력이 큰 명령은 범위를 제한한다.
지표 해석
| 신호 | 먼저 의심할 것 | 다음 확인 |
|---|---|---|
| GC 후 heap used가 계속 상승 | heap leak 또는 cache 증가 | class histogram, heap dump |
| heap은 안정적인데 RSS 상승 | native/direct memory, thread stack | NMT, /proc/<pid>/status |
| Full GC와 pause 증가 | allocation pressure 또는 old gen 압박 | GC log, allocation hot spot |
| Swap in/out 발생 | OS memory pressure | vmstat, container limit, OOM kill log |
Heap Dump와 메모리 장애 대응에서는 핵심 신호와 보조 지표를 같은 시간축에서 맞춘다. 먼저 변한 신호와 뒤따라 포화된 신호를 분리해야 원인과 결과를 구분할 수 있다.
장애 상황에서 보는 순서
- class histogram으로 증가한 타입을 먼저 확인한다.
- dump 수집이 가능한 disk 용량, 권한, 보안 조건을 확인한다.
- OOM 직전 또는 leak이 충분히 누적된 시점에 dump를 남긴다.
- MAT 등으로 retained size와 GC root path를 본다.
- 수정 후 같은 부하에서 GC 후 baseline이 회복되는지 검증한다.
이 순서는 heap dump를 마지막 수단이 아니라 통제된 증거로 쓰기 위한 루틴이다.
실전 팁
- dump 전에는 disk 여유 공간, dump 경로, 파일 권한을 확인한다.
- histogram을 2회 이상 남기면 계속 증가하는 class를 먼저 볼 수 있다.
- heap dump는 분석용 저장소로 옮기고 운영 서버에 오래 두지 않는다.
- OOM 자동 dump 옵션은 경로와 용량 제한을 함께 설정한다.
- dump 분석 결과는 retained size와 참조 경로 중심으로 기록한다.
주니어 팁
Heap Dump와 메모리 장애 대응주제는 용어 정의보다 장애 때 어떤 증거로 확인할지까지 연결해 익힌다.- 정상 상태에서 이 문서의 관찰 명령을 실행해
Heap Dump와 메모리 장애 대응기준선을 남긴다. - 장애 시에는
Heap Dump와 메모리 장애 대응신호가 평소 기준선에서 벗어난 시각과 방향을 먼저 본다.
시니어 팁
Heap Dump와 메모리 장애 대응주제의 영향이 pool, queue, retry, timeout으로 번지는 경로를 설계 리뷰에 포함한다.Heap Dump와 메모리 장애 대응runbook에는 실행 명령, 정상 범위, 해석 기준, 금지할 대응을 같이 둔다.Heap Dump와 메모리 장애 대응판단이 container, LB, 다중 인스턴스 환경에서도 같은 의미인지 확인한다.
Guru급 팁
Heap Dump와 메모리 장애 대응주제는 단일 snapshot보다 변화 방향이 중요하다. 같은 명령을 간격을 두고 실행해 상태가 증가, 유지, 회복 중 어디인지 본다.- 고급 도구는
Heap Dump와 메모리 장애 대응가설을 좁힐 때만 사용하고 기본 지표와 모순되는지 먼저 확인한다. Heap Dump와 메모리 장애 대응조치 후에는 CPU, memory, socket, disk, pool 중 다음 포화 지점이 어디로 이동했는지 확인한다.
위험 신호!
- dump를 남길 disk가 부족해 장애 중 disk full을 만든다.
- dump 파일 권한이 넓어 개인정보나 토큰이 노출된다.
- class histogram 없이 큰 dump만 반복해서 남긴다.
- OOM 후 재시작이 빨라 dump 파일이 남지 않는다.
- heap dump로 native/direct memory 문제를 찾으려 한다.
확인 질문
확인 질문
Heap Dump와 메모리 장애 대응주제를 장애 중 확인할 때 Application 로그만으로 부족한 이유는 무엇인가?
- 로그는 코드 경로를 보여 주지만
Heap Dump와 메모리 장애 대응의 JVM/OS 자원 상태, 대기 위치, 포화 방향은 별도 지표로 확인해야 하기 때문이다.Heap Dump와 메모리 장애 대응관련 설정이나 pool 크기를 바꾸기 전에 확인할 것은 무엇인가?
- 먼저 변한 신호, 하위 자원 capacity, 변경이 완화인지 증폭인지 판단할 기준을
Heap Dump와 메모리 장애 대응지표로 확인해야 한다.Heap Dump와 메모리 장애 대응재발을 막기 위해 장애 기록에 무엇을 남겨야 하는가?
- 발생 시간, 영향 범위, 사용한 명령,
Heap Dump와 메모리 장애 대응핵심 지표, 원인 판단, 완화 조치, 근본 수정, 남은 리스크를 남긴다.