이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
JVM Option과 운영 판단에서 붙잡아야 할 핵심 판단 기준은 무엇인가?JVM option은 운영 정책이다라는 기준은 어떤 JVM/OS 신호로 확인되는가?- Java/Spring 코드에서
Spring BootJAVA_TOOL_OPTIONS“ 흐름은 어떤 장애 신호로 드러나는가?
개요
이 문서의 주제는 JVM Option과 운영 판단이다. Heap, GC, dump, log, container 관련 JVM option을 운영 판단과 연결한다.
먼저 붙잡을 기준은 다음 문장이다. JVM option은 운영 정책이다. Heap 크기, GC 종류, dump 경로, GC log, container memory 비율은 성능 마법값이 아니라 장애 시 어떤 증거를 남기고 어떤 한계 안에서 실행할지 정하는 계약이다.
핵심 모델
- 판단 기준: JVM option은 운영 정책이다.
- JVM option은 heap, GC, dump, log, container limit, diagnostics 정책을 결정한다.
- 실제 적용 option은 배포 설정이 아니라
VM.command_line,VM.flags로 확인한다. -Xmx를 키우면 heap 여유는 늘지만 native memory와 page cache 여유는 줄 수 있다.HeapDumpOnOutOfMemoryError, GC log, JFR 옵션은 장애 증거 보존 정책이다.- Option 변경은 부하 조건, 지표 전후 비교, rollback 계획과 함께 관리해야 한다.
문서별 핵심 구분
- JVM option은 heap, GC, dump, log, container limit에 대한 운영 계약이다.
- 실제 적용 option은 command line과 VM.flags로 확인해야 한다.
- option 변경은 성능 실험 결과와 함께 남겨야 한다.
원리
JVM option은 실행 시점의 runtime 계약이다. 같은 jar라도 -Xmx, GC 종류, active profile, dump path, log path가 다르면 장애 양상이 달라진다.
운영 판단에서 가장 먼저 할 일은 “내가 의도한 option이 실제 process에 적용됐는가”를 확인하는 것이다. 배포 스크립트, systemd unit, container env, entrypoint가 서로 다를 수 있다.
Heap option은 container limit과 함께 봐야 한다. Heap을 너무 크게 잡으면 metaspace, direct memory, thread stack, OS page cache 여유가 줄어 OOM kill이나 latency 악화를 만들 수 있다.
Diagnostics option은 장애 때 증거를 남기는 안전장치다. Heap dump와 GC log는 path, 권한, disk 여유, 민감 정보 보관 정책까지 포함해야 운영 계약이 된다.
Java/Spring 연결
- Spring Boot
JAVA_TOOL_OPTIONS, systemdEnvironment, container env, entrypoint가 모두 JVM option을 바꿀 수 있다. - Actuator가 보여 주는 heap/GC 지표는 실제
VM.flags와 함께 봐야 해석할 수 있다. - Heap dump와 GC log 경로는 service user 권한과 disk 용량을 만족해야 한다.
- Container에서는
MaxRAMPercentage,InitialRAMPercentage,-Xmx가 실제 memory limit과 맞는지 확인한다. - Option 변경은 배포 변경처럼 버전, 이유, 기대 효과, rollback 조건을 남긴다.
코드와 설정 예시
jcmd <pid> VM.flags
jcmd <pid> VM.command_line
jcmd <pid> VM.system_properties | head예시는 배포 설정이 아니라 실행 중인 JVM이 실제로 받은 option을 확인하는 흐름이다. 장애 보고서에는 의도한 설정과 실제 command line 차이를 같이 남긴다.
관찰 명령
jcmd <pid> VM.flags
jcmd <pid> VM.command_line
jcmd <pid> VM.system_properties | headJVM Option과 운영 판단 관찰 명령은 결론이 아니라 가설 확인 도구다. 운영 중에는 반복 간격, 대상 PID, 수집 시각을 함께 남기고 출력이 큰 명령은 범위를 제한한다.
지표 해석
| 신호 | 먼저 의심할 것 | 다음 확인 |
|---|---|---|
| 의도한 option과 실제 flags 불일치 | 배포/env/entrypoint 차이 | VM.command_line, unit/env |
| Heap은 여유, RSS limit 근접 | heap 밖 memory 부족 | metaspace, direct, stack |
| OOM dump 없음 | diagnostics option/path 문제 | dump option, disk, 권한 |
| Option 변경 후 지표 악화 | 근거 없는 튜닝 | 전후 latency/GC/CPU 비교 |
Option 판단은 변경 시각과 전후 지표가 핵심이다. GC pause, heap 여유, RSS 압박, dump/log 경로 문제가 변경 직후 어떻게 달라졌는지 남겨야 한다.
장애 상황에서 보는 순서
VM.command_line과VM.flags로 실제 option을 확인한다.- 배포 설정, systemd unit, container env와 실제 process를 비교한다.
- Heap, RSS, container limit, dump/log path 권한을 확인한다.
- Option 변경 전후의 latency, GC, CPU, memory 지표를 같은 부하 조건에서 비교한다.
- 변경 이유와 rollback 조건을 장애 기록에 남긴다.
이 순서는 option을 성능 주문처럼 바꾸지 않기 위한 루틴이다. 실제 flags, 부하 조건, 전후 지표, rollback 조건이 없으면 운영 변경으로 인정하기 어렵다.
실전 팁
- JVM option은 실행 중인 process 기준으로 확인한다.
- Heap 크기는 container limit과 heap 밖 memory 여유를 빼고 정한다.
- GC log와 heap dump option은 path, 권한, disk, 민감 정보 정책까지 포함한다.
- Option 변경은 성능 실험이 아니라면 장애 중 임시 조치로 기록한다.
- 장애 회고에는 변경 전후
VM.flags와 핵심 지표를 함께 남긴다.
주니어 팁
- JVM option은 애플리케이션 설정만큼 운영에 영향을 준다.
- 문서에 적힌 값보다 실행 중 process의
VM.flags가 더 강한 증거다. -Xmx를 키우면 항상 안전해지는 것이 아니라 heap 밖 여유가 줄어들 수 있다.
시니어 팁
- JVM option은 코드와 같은 변경 관리 대상으로 둔다.
- Container 표준에는 memory limit, heap percentage, dump/log path, GC log 보관 정책을 포함한다.
- Option 변경은 canary나 부하 재현 조건에서 검증한 뒤 전체 적용한다.
Guru급 팁
- JVM option diff는 릴리스 노트에 남길 가치가 있다. 같은 jar도 option이 다르면 다른 runtime으로 봐야 한다.
- Dump와 GC log option은 장애 증거 정책이므로 retention, 암호화, 접근 권한, disk quota까지 같이 설계한다.
MaxRAMPercentage기반 표준을 쓰더라도 서비스별 direct memory, thread 수, native library 사용량에 따라 예외 기준을 둔다.
위험 신호!
- 배포 설정만 보고 실제 JVM option을 확인하지 않는다.
- Heap을 키우면서 metaspace/direct/stack 여유를 계산하지 않는다.
- Heap dump path 권한과 disk 용량을 확인하지 않는다.
- GC option을 바꾸고 전후 GC log와 latency를 비교하지 않는다.
- 긴급 option 변경을 정식 운영 설정으로 남겨 둔다.
확인 질문
확인 질문
- 실제 JVM option을 확인할 때 가장 신뢰할 증거는 무엇인가?
- 실행 중 process의
VM.command_line과VM.flags다.-Xmx를 키우기 전에 확인해야 할 것은 무엇인가?
- Container limit, RSS, metaspace/direct/thread stack, OS page cache, GC pause와 allocation 지표를 확인해야 한다.
- JVM option 변경 기록에는 무엇을 남겨야 하는가?
- 변경 이유, 변경 전후 flags, 부하 조건, latency/GC/CPU/memory 지표, rollback 조건을 남겨야 한다.