문제 요약
Pod에 10Gi 제한 설정 및 JVM에 -Xms4g -Xmx6g 설정을 했음에도 불구하고 heap 메모리 부족으로 OOM 발생
원인 분석
- 대용량 byte array 처리 및 누적된 문자열 → heap 사용 급증
- 단일 Step 내 모든 파일을 순차 로드하여 누수 발생 가능
- GC가 즉시 해제하지 못하는 구조
해결 방안
- Java 실행 옵션에 아래 추가
-XX:+UseG1GC-XX:+UseStringDeduplication
- 객체 null 처리 후 명시적 GC 유도 (필요 시)
- 가능한 경우 S3에서 스트리밍 방식 처리 (파일 직접 전체 로드 지양)
일반적으로 다음 비율이 안전:
| Memory Limit | 최대 Xmx 권장 값 (안전 범위) |
|---|---|
| 10Gi | -Xmx7g 또는 -Xmx8g |
| 16Gi | -Xmx12g 정도까지 |
| 20Gi | -Xmx16g까지도 가능 |
- 나머지 20~30%는 Metaspace, CodeCache, GC overhead, Thread Stack 등에 사용됨
-XX:+UseG1GC는 Heap 사이즈가 커질수록 안정적이지만, Full GC 시간이 길어질 수 있음
추천 세팅 (10Gi 제한 시)
-Xms6g -Xmx8g \
-XX:+UseG1GC \
-XX:+UseStringDeduplication \
-XX:MaxMetaspaceSize=256m \
-XX:MaxDirectMemorySize=512m
GC 튜닝 여유를 위해 Metaspace/DirectMemory도 명시하면 좋다.
추가 팁
- GC 로그 추가해서 튜닝 근거 확보 가능
-Xlog:gc*:file=/app_log/gc.log:time,uptime,level,tags
- OOM 직전에는
Thread Dump남기는 것도 좋다.