컨테이너 환경에 따른 GC 전략

도커 컨테이너로 자바 애플리케이션을 실행한 후 모니터링을 하다보니 제가 알고 있던 가비지 컬렉션 동작과는 다르다는 것을 발견했습니다. 

당시 Oracle Linux Server 리눅스 서버와 openjdk 21를 사용했습니다. 추가로 컨테이너 메모리를 1GB로 제한하였습니다. 이렇게 구성하였을 때 아래와 같이 GC 로그와 자바 버전을 출력해보았습니다.

bash-4.4# java -Xlog:gc --version
[0.002s][info][gc] Using Serial
openjdk 21 2023-09-19
OpenJDK Runtime Environment (build 21+35-2513)
OpenJDK 64-Bit Server VM (build 21+35-2513, mixed mode, sharing)

여기서 첫 번째 줄을 보니 GC 전략이 Serial로 되있다는 것을 발견하였습니다.

Java Ergonomics

HotSpot Virtual Machine Garbage Collection Tunning Guide

HotSpot Virtual Machine Garbage Collection Tuning Guide

가비지 컬렉터, 힙 크기 및 런타임 컴파일러 기본 선택 사항에 대한 내용을 담고 있는 내용입니다. 아래와 같이 정리할 수 있습니다.

• 서버급 시스템에서는 G1 컬렉터, 그렇지 않으면 Serial 컬렉터.
• 최대 GC 스레드 수는 힙 크기와 사용 가능한 CPU 리소스에 의해 제한
• 초기 힙 크기 : 물리적 메모리의 1/64
• 최대 힙 크기는 실제 메모리의 1/4
• 계층형 컴파일어, C1과 C2 모두 사용

여기서 주목했던 건 당연히 첫 번째 항목입니다. 여기서 말하는 서버급 시스템의 기준은 무엇일까요? 이에 대한 내용도 언급되어 있는데 VM이 두 개 이상의 프로세서와 1792MB 이상의 힙 크기를 감지하면 VM은 머신을 서버급으로 간주한다고 합니다.

즉 위에서 제가 경험했던 문제는 컨테이너에 1GB 메모리 제한을 걸게됨으로서 위에서 얘기하는 서버급 시스템이 아니게 되어 Serial 컬렉터가 사용됬다라는 것을 알 수 있었습니다.

따라서 도커 컨테이너 메모리 제한을 2GB로 설정한 후 다시 GC 로그를 출력해보면 아래와 같이 G1 컬렉터가 사용되는 것을 볼 수 있습니다.

bash-4.4# java -Xlog:gc --version
[0.002s][info][gc] Using G1
openjdk 21 2023-09-19
OpenJDK Runtime Environment (build 21+35-2513)
OpenJDK 64-Bit Server VM (build 21+35-2513, mixed mode, sharing)