-Xms 보다 Memory 사용량이 더 적은 이유
Logstash 는 JVM 에서 동작중이며 -Xms (최소 힙 크기 사이즈) 는 1g 로 실행되었다.
하지만 메트릭에서 보는 것 처럼 Java process 가 사용하는 메모리는 572MB 로 최소 힙 크기보다 적은 양의 메모리를 사용하고 있다고 메트릭은 표현하고 있다.
어떻게 최소 힙 크기보다 적은 양의 메모리를 사용하고 있을까? 라는 궁금증이 생겼다.
우선 해당 메트릭은 Kubernetes 의 cAdvisor 에 의해서 수집되는 지표이다.
cAdvisor 가 수집하는 여러가지 메모리 지표중 container_memory_working_set_bytes 를 사용하여 메모리 사용량을 나타내고 있다.
cAdvison 코드에 보면 container_memory_working_set_bytes 는 아래와 같이 설명되어있다.
The amount of working set memory, this includes recently accessed memory, dirty memory, and kernel memory. Working set is <= "usage".
Units: Bytes.
또한, OS 에서 working set 이라는 용어는 Virutal Memory 의 Page 를 물리 메모리에 올릴때 Thrasing 이 빈번히 발생하여 CPU 활용성이 떨어지는 것을 보안하고자 자주 접근하는 메모리를 Swap out 하지 않고 메모리에 상주시키는 기법을 의미한다. Working set 은 현재 실행중인 프로세스 전용으로 할당된 메모리 집합이라고도 할 수 있다.
위 설명들을 종합해보면 container_memory_working_set_bytes 는 해당 프로세스가 점유하고 있는 물리 메모리 크기라고 할 수 있다. 해당 서버에 접속하여 top 명령어를 사용하면 아래와 같은 결과가 보여진다.
top - 14:21:42 up 13 days, 11:03, 0 users, load average: 0.15, 0.10, 0.09
Tasks: 7 total, 1 running, 6 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.1 us, 0.1 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 32118980 total, 16675472 free, 7875952 used, 7567556 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 23870064 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 4640112 587188 21768 S 0.0 1.8 3:25.12 java
56 root 20 0 20264 3888 3420 S 0.0 0.0 0:00.01 bash
85 root 20 0 20264 3928 3460 S 0.0 0.0 0:00.00 bash
126 root 20 0 20264 3884 3416 S 0.0 0.0 0:00.01 bash
192 root 20 0 20264 3840 3408 S 0.0 0.0 0:00.00 bash
213 root 20 0 20264 3768 3344 S 0.0 0.0 0:00.00 bashjava process
- VIRT : 4.4GB
- RES : 0.55GB
- SHR : 0.02GB
top 명령어의 VIRT, RES,SHR 의 의미를 먼저 찾아봐야할 것 같다.
- VIRT (Virtual Memory Size) : Process 에 의해서 사용되는 모든 가상메모리의 키기. Virtual Memory 는 모든 코드, 데이터, 공유 라이브러리를 포함한다. 또한 swapped out 된 page 들도 포함한다.
- RES (Resdient Memory Size) : VIRT 중 해당 프로세스가 현재 사용중인 물리 메모리 크기. swapped-out 된 페이지는 포함하지 않는다.
- SHR (Shared Memory Size) : RES 중 다른 프로세스와 공유되고 있는 메모리 크기.
프로세스는 가상 메모리 주소를 받아서 프로세스 실행에 필요한 메모리만 물리 메모리에 올려서 사용하게 된다. 그렇게 물리 메모리에 load 된 메모리 크기를 RES 가 나타낸다. container_memory_working_set_bytes 의 값과 RES 값이 거의 일치하는것을 확인할 수 있다.
JVM 에서 최소 heap size 를 1g 로 지정하였지만 1g 를 물리 메모리에 올려놓고 점유하고 있는 것이 아니라 가상메모리에는 1기가를 잡아놓고 실제 힙에 객체가 할당될때 그 물리 메모리에 그 객체를 올리게 된다.
가상 메모리에는 연속된 Heap 공간이라고 하더라도 물리 메모리에는 page 단위로 나누어져 할당 될 수 있기에 가능한 것이다. 만약 page 기술이 없었다면 물리 메모리에 힙 사이즈 만큼 미리 할당해야할 수도 있었겠다. G1GC 는 logical memory 상에서도 각 Generation 이 연속하지 않는다.
결론
JVM 에게 -Xms1g 로 주었지만 힙에 실제로 객체를 할당하기 전까지는 물리 메모리에 올라가지 않기 때문에 physical memory 의 working set 에 잡히지 않게 된다. 때문에 -Xms 보다 container_memory_working_set_bytes 가 더 작을 수 있는 것이다.
이러한 현상은 CMS GC 를 사용하는 java process 에서 더 두드러지게 나타난다. CMS GC 는 -XX:newRatio 를 지정하지 않으면 전체 Heap size 중 10% 크기만 Young 영역으로 할당하게 된다.
Old 영역으로 객체가 넘어가 Major GC 가 일어나기 전까지는 모두 물리 메모리를 점유하고 있기 때문에 Old 영역에 객체가 할당될때마다 메모리 사용량이 증가하는것이 보이게 된다. Major GC 는 빈번하게 발생하지 않기 때문에!
다시 생긴 의문
하지만 GC 가 일어난다고해서 working_set_bytes 가 줄어들지 않는 이유는 무엇일까..
가능성1)
이 질문에 보면 JVM 이 GC 를 한다고 하더라도 메모리를 OS 에게 돌려주지 않는다고 한다.
가능성2)
Swap 을 사용하지 않도록 OS 에 설정되어있어서 GC 된 메모리라고 하더라도 swap out 되지 않고 JVM 이 계속 점유하는건 아닐까?
total used free shared buff/cache available
Mem: 32411416 4866640 21293608 10168 6251168 27178404
Swap: 0 0 0
가능성3)
Working Set Model 에 의해서 OS 가 Java process 가 자주 접근하는 frame 은 page fault 를 줄이기 위해 회수하지 않는 것일까?
나름 다시 정리
JVM 의 Heap 은 Virtual Memory 로는 잡혀있지만 객체가 할당되기 전까지는 물리 메모리에 올라가지 않는다
객체가 할당되면 물리 메모리를 점유하게되고 RSS 가 증가한다
하지만 그 객체가 GC 된다고 하더라도 JVM 은 물리 메모리를 OS 에 돌려주지 않고
다른 객체를 해당 물리 메모리에 할당하여 사용한다