이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
Virtual Memory Paging Swap에서 붙잡아야 할 핵심 판단 기준은 무엇인가?주소 공간과 실제 memory pressure를 구분한다라는 기준은 어떤 JVM/OS 신호로 확인되는가?- Java/Spring 코드에서
Virtual Memory Paging Swap판단 기준은 어떤 장애 신호로 드러나는가?
개요
이 문서의 주제는 Virtual Memory Paging Swap이다. OS virtual memory, page fault, swap이 Java 서버 지연에 미치는 영향을 설명한다.
먼저 붙잡을 기준은 다음 문장이다. 주소 공간과 실제 memory pressure를 구분한다. 이 문서는 이 기준을 Java/Spring 실행 흐름, JVM/OS 관찰 지표, 장애 판단 순서로 연결한다.
핵심 모델
- 판단 기준: virtual memory 크기와 실제 memory 압박은 다르다.
- Virtual memory는 process가 보는 주소 공간이고 RSS는 실제 물리 memory에 올라온 부분이다.
- Page fault는 주소 공간의 page를 실제 memory나 disk와 맞추는 과정에서 발생한다.
- Swap이 사용되면 memory 부족을 늦출 수 있지만 latency가 급격히 나빠질 수 있다.
- Container에서는 host memory보다 cgroup limit과 OOM event가 더 직접적인 기준이다.
문서별 핵심 구분
- virtual memory는 process가 보는 주소 공간이다.
- page fault와 swap은 Java latency를 크게 흔들 수 있다.
- container memory limit에서는 OS kill도 OOM 형태로 나타난다.
원리
Virtual memory는 process가 보는 주소 공간이고, RSS는 실제 물리 memory에 올라와 있는 부분이다. VmSize가 크다고 곧바로 장애는 아니지만, RSS가 limit에 가까워지고 page fault와 swap이 늘면 응답 지연으로 이어진다.
Paging은 필요한 page를 memory에 올리거나 내리는 과정이다. minor fault는 이미 memory에 있는 page mapping 비용이고, major fault는 disk I/O를 동반할 수 있어 latency에 훨씬 큰 영향을 준다.
Swap은 부족한 물리 memory를 disk로 밀어내는 장치다. 서버 애플리케이션에서 swap in/out이 발생하면 CPU가 낮아도 요청이 느려질 수 있고, GC pause나 thread 대기처럼 보일 수 있다.
Virtual Memory Paging Swap 관점에서 중요한 점은 Java heap 지표와 OS memory pressure를 분리하는 것이다. heap은 안정적인데 vmstat의 si/so가 움직이거나 cgroup OOM kill이 발생하면 JVM 내부 누수만으로 설명해서는 안 된다.
Java/Spring 연결
- JVM
-Xmx가 낮아도 RSS는 thread stack, direct buffer, metaspace 때문에 커질 수 있다. - GC가 자주 돌지 않아도 OS memory pressure나 swap 때문에 API latency가 늘 수 있다.
- Kubernetes/cgroup OOM kill은 Java exception 없이 process 종료로 보일 수 있다.
- Page cache 여유가 줄면 file I/O와 log write latency도 같이 나빠진다.
- Actuator memory 지표만으로 swap과 cgroup pressure를 설명할 수 없다.
코드와 설정 예시
heap used after GC 안정
RSS 증가
container memory.current 증가
vmstat si/so 또는 major fault 증가
-> JVM heap보다 OS memory pressure를 먼저 의심예시는 memory 문제를 heap 하나로 단정하지 않기 위한 판단 흐름이다. RSS, cgroup limit, page fault, swap 지표가 움직이면 Java 객체 누수와 별도로 OS memory pressure를 확인해야 한다.
관찰 명령
free -h
vmstat 1 5
cat /proc/meminfo | head
cat /proc/<pid>/status | grep VmRSSVirtual Memory Paging Swap 관찰 명령은 결론이 아니라 가설 확인 도구다. 운영 중에는 반복 간격, 대상 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 |
Virtual Memory Paging Swap에서는 핵심 신호와 보조 지표를 같은 시간축에서 맞춘다. 먼저 변한 신호와 뒤따라 포화된 신호를 분리해야 원인과 결과를 구분할 수 있다.
장애 상황에서 보는 순서
free,vmstat, cgroup memory event로 swap과 pressure를 본다.- JVM heap 사용량과 process RSS가 함께 증가하는지 나눈다.
- OOM kill 기록과 container restart reason을 확인한다.
- page fault, major fault, disk I/O 증가가 latency와 맞물리는지 본다.
- heap 조정보다 process 전체 memory budget을 먼저 다시 계산한다.
이 순서는 JVM 내부 memory와 OS paging 문제를 구분하기 위한 루틴이다.
실전 팁
VmSize,VmRSS, cgroup memory 사용량을 같은 시간대에 본다.vmstat의si/so가 움직이면 swap으로 인한 latency 가능성을 먼저 표시한다.- major page fault가 늘면 disk I/O와 memory pressure를 함께 확인한다.
- container OOM kill은 Java
OutOfMemoryError로그 없이 process 종료로 보일 수 있다. - swap을 임시 완화로 허용하더라도 서버 latency 목표와 맞는지 별도로 판단한다.
주니어 팁
Virtual Memory Paging Swap주제는 용어 정의보다 장애 때 어떤 증거로 확인할지까지 연결해 익힌다.- 정상 상태에서 이 문서의 관찰 명령을 실행해
Virtual Memory Paging Swap기준선을 남긴다. - 장애 시에는
Virtual Memory Paging Swap신호가 평소 기준선에서 벗어난 시각과 방향을 먼저 본다.
시니어 팁
Virtual Memory Paging Swap주제의 영향이 pool, queue, retry, timeout으로 번지는 경로를 설계 리뷰에 포함한다.Virtual Memory Paging Swaprunbook에는 실행 명령, 정상 범위, 해석 기준, 금지할 대응을 같이 둔다.Virtual Memory Paging Swap판단이 container, LB, 다중 인스턴스 환경에서도 같은 의미인지 확인한다.
Guru급 팁
Virtual Memory Paging Swap주제는 단일 snapshot보다 변화 방향이 중요하다. 같은 명령을 간격을 두고 실행해 상태가 증가, 유지, 회복 중 어디인지 본다.- 고급 도구는
Virtual Memory Paging Swap가설을 좁힐 때만 사용하고 기본 지표와 모순되는지 먼저 확인한다. Virtual Memory Paging Swap조치 후에는 CPU, memory, socket, disk, pool 중 다음 포화 지점이 어디로 이동했는지 확인한다.
위험 신호!
free의 free memory만 보고 page cache와 available memory를 보지 않는다.- swap in/out이 있는데 GC 튜닝만 계속한다.
- container limit과 JVM
MaxRAMPercentage관계를 확인하지 않는다. - OS OOM kill을 애플리케이션 예외와 같은 방식으로만 찾는다.
- RSS가 증가하는데 heap dump만 반복해서 남긴다.
확인 질문
확인 질문
Virtual Memory Paging Swap주제를 장애 중 확인할 때 Application 로그만으로 부족한 이유는 무엇인가?
- 로그는 코드 경로를 보여 주지만
Virtual Memory Paging Swap의 JVM/OS 자원 상태, 대기 위치, 포화 방향은 별도 지표로 확인해야 하기 때문이다.Virtual Memory Paging Swap관련 설정이나 pool 크기를 바꾸기 전에 확인할 것은 무엇인가?
- 먼저 변한 신호, 하위 자원 capacity, 변경이 완화인지 증폭인지 판단할 기준을
Virtual Memory Paging Swap지표로 확인해야 한다.Virtual Memory Paging Swap재발을 막기 위해 장애 기록에 무엇을 남겨야 하는가?
- 발생 시간, 영향 범위, 사용한 명령,
Virtual Memory Paging Swap핵심 지표, 원인 판단, 완화 조치, 근본 수정, 남은 리스크를 남긴다.