컨테이너에서 JVM은 왜 메모리 먹는 하마였을까?

📍 Epilogue

---

• 간단한 JAR 애플리케이션을 가지고 쿠버네티스 파드 배포를 시도하였다 !
• 그런데 컨테이너 상태가.. 엄청난 메모리 부족..
  • OOM Killed.. CrashLoopBackOff 상태 반복..
• 파드 스펙 늘리고 다시 배포하니 정상 상태 !
• 그래서 여기서 의문점 ❗️
  • JVM은 원래 메모리를 많이 잡아 먹는가? → 구조 때문? → 한 번 파헤쳐보자!

 

▪︎ JVM이란 ?

---

💡 JVM : 자바 가상 머신 (Java Virtual Machine)

 

• OS에 상관없이 자바 바이트 코드를 실행 시킬 수 있는 자바 가상 머신
• 자바 코드를 컴파일해서 얻은 바이트 코드를 OS가 이해할 수 있는 기계어로 바꿔 실행

 

 

 

▪︎ 컴파일 과정

---

💡 .java → 소스 코드 (Source Code)
     .class → 바이트 코드 (Byte Code)
     기계어 → 바이너리 코드 (Binary Code)

 

• Test.java → Javac.exe (Compiler) → Test.class → OS

Javac.exe (Compiler)
• JDK를 설치하면 bin에 존재하는 컴파일러 실행 파일

 

1. Test.java → Javac.exe (Compiler)
   • Java 소스 코드를 Java 바이트 코드로 변환하기 위해 컴파일러 실행한다.
2. Javac.exe (Compiler) → Test.class
   • 컴파일하여 .java 파일(Source code)을 .class 파일(Byte code)로 변환한다.
3. Test.class → OS
   • JVM이 바이트 코드를 OS가 해석할 수 있는 바이너리 코드(기계어)로 변환한다.

 

 

▪︎ JVM 구조

---

• Class Loader
  • .java 소스 파일을 컴파일해서 나온 .class 클래스 파일을 묶어
  • OS로부터 할당 받은 메모리 영역 Runtime Data Area로 적재하는 역할
• Execution Engine
  • Runtime Data Area 메모리에 적재된 클래스들을 기계어로 변경해 실행하는 역할
    • Interpreter
      • 자바 바이트 코드를 명령어 단위로 하나씩 실행
    • JIT (Just-In-Time)
      • 적절한 시점에 전체 바이트 코드를 기계어로 컴파일하여 실행
• Garbage Collector (GC)
  • Heap 메모리에 생성된 객체들 중에서 참조되지 않는 객체들을 탐색한 후 제거하는 역할
  • GC가 수행하는 동안 GC를 수행하는 쓰레드 외에 모든 쓰레드가 일시 정지한다.
• Runtime Data Area
  • 자바 애플리케이션을 실행하기 위해 OS에서 할당받은 메모리 영역
    • Method Area
      • 클래스의 정보를 처음 메모리에 저장할 때 초기화되는 대상을 저장하기 위한 공간
      • e.g.) 클래스 멤버 변수 이름, 타입, 리턴 타입, 파라미터, 메소드 이름, 정보 등..
    • Heap Area
      • new로 인해 생성된 객체와 배열이 저장되는 공간
      • Method Area에 있는 클래스들로만 객체 생성 가능
      • GC가 참조되지 않는 객체들을 제거하는 공간
    • Stack Area
      • 실행 과정에서 임시로 할당되었다가 메소드를 빠져나가면 바로 소멸되는 특성의 데이터 저장하는 공간
      • 메소드를 호출할 때마다 개별적으로 스택 공간 생성
      • e.g.) 지역 변수, 매개 변수, 리턴 값, 임시 데이터, 스레드 등..
    • PC Register
      • Thread가 생성될 때마다 생성되는 공간
      • Thread가 현재 실행되는 부분의 주소와 명령을 저장 (=Program Counter)
    • Native Method Stack
      • 자바 외 언어 (C, C++ 등..)의 코드를 수행하기 위한 스택 공간
      • JNI (Java Native Interface)을 통해 바이트 코드로 전환하여 저장
      • 커널이 스택을 잡아서 독자적으로 프로그램을 실행 (=일반 프로그램)

 

아무래도 JVM은 어떤 OS에서도 자바 코드를 실행할 수 있도록 하는 VM이기 때문에 이러한 특성 때문에 자원 할당량이 높다고 생각하였다.

 

• 그러면 여기서 생각해볼 수 있는 현 상황의 해결법 🔨

1. JVM 메모리 할당을 줄이기
2. 컨테이너 자원 리소스 할당 늘리기
   • 쉽게 해결할 수 있는 방법이지만 리소스 낭비가 초래될 수 있다고 생각함

 

 

▪︎ JVM 메모리 줄이기

---

• 기본적으로 JVM은 Heap 메모리 사이즈를 물리적인 메모리의 25% 값을 할당한다. ( ≥ JDK 10 )
• Pod 메모리 구성
  • JVM - Heap
  • JVM - Non Heap
  • System
  • IDLE
• Total Memory - Heap Memory - ( Non-Heap Memory + System + IDLE ) = Remain Memory

 

• System의 기본적인 메모리 사용량을 모니터링 한 후에 Remain Memory 계산 및 고려하여 최대 Heap Memory 사이즈를 설정해야 한다.

 

• JAR을 실행시킬 때 JVM의 Heap Area의 메모리 크기를 조절해주는 옵션이 있다.
• -Xms256m
  • 메모리의 최초 크기 256MB 설정
• -Xmx512m
  • 메모리의 최대 크기 512MB 설정

 

• 그러나 K8s Container 환경에서 JVM에 직접 메모리를 조정하는 -Xms / -Xmx 옵션보다 Container 자원에 따라 조절할 수 있는 UseContainerSupport 옵션을 사용한다.
• K8s Pod 생성 시 Container의 자원을 설정(requests, limits)할 수 있기 때문이다.
  • Default = True
  • ≥ OpenJDK 8 지원

 

• -XX:InitialRAMPercentage=40 (%)
  • JVM의 초기 Heap 메모리 크기 설정
  • e.g.) 컨테이너의 메모리가 1GB인 경우 JVM 초기 Heap 메모리 크기는 400MB (1GB의 40%)
• -XX:MinRAMPercentage=50 (%)
  • 200MB 미만의 초기 Heap 메모리 크기를 가진 JVM의 최대 Heap 메모리 크기 설정
• -XX:MaxRAMPercentage=70 (%)
  • 200MB 초과의 초기 Heap 메모리 크기를 가진 JVM의 최대 Heap 메모리 크기 설정

 

 

 

본의 아니게 이슈가 다른 방법으로 해결이 되어서 이슈가 사라졌다ㅠㅜ
이슈 재현을 시도하였지만 아직까지 재현에 실패한 상태..
으.. 적용해보고 싶다 !!

 

 

 

ref. JVM Structure

---

JVM 구조와 자바 런타임 메모리 구조 (자바 애플리케이션이 실행될 때 JVM에서 일어나는 일, 과정을 설명해줄 수 있나요?)

[JAVA] JVM이란? 개념 및 구조 (JDK, JRE, JIT, 가비지 콜렉터...)

 

ref. JVM Memory Setting

---

컨테이너 환경에서 JVM Memory 설정

컨테이너 환경에서의 java 애플리케이션의 리소스와 메모리 설정

 

ref. Other Case

---

JVM + Container 환경에서 수상한 Memory 사용량 증가 현상 분석하기