64비트 환경에서 왜 힙 메모리를 32gb 이하로 설정해야 할까?
Compressed OOPs: 32비트 포인터로 32GB 메모리를 다루는 마법
많은 ES Java 개발자들이 서버 설정을 할 때 "힙 메모리는 시스템 메모리의 절반, 하지만 최대 32GB를 넘기지 마라"는 가이드를 접한다. 64비트 시스템이라면 이론적으로 수 페타바이트의 주소 공간을 가질 수 있는데, 왜 우리는 굳이 32GB라는 제약 속에 갇혀야 할까?
그 비밀은 바로 JVM의 성능 최적화 기술인 Compressed OOPs(Ordinary Object Pointers)에 있다.
1. 포인터의 딜레마: 32-bit vs 64-bit
자바에서 객체를 가리키는 포인터를 OOP(Ordinary Object Pointer)라고 한다.
32-bit 환경: 포인터 하나가 32비트이다.. 2^32 바이트, 즉 최대 4GB까지만 주소를 지정할 수 있다.
64-bit 환경: 포인터가 64비트로 늘어난다. 주소 공간은 무한에 가깝지만, 포인터 크기가 2배가 되면서 메모리 낭비가 심해지고 CPU 캐시 효율이 떨어지는 부작용이 생긴다.
2. 마법의 기술, Compressed OOPs
JVM은 64비트 환경에서도 힙 메모리가 특정 범위(약 32GB) 이내라면 포인터를 32비트인 것처럼 압축해서 관리하는 기술을 사용한다. 어떻게 32비트(2^32)로 4GB가 아닌 32GB를 가리킬 수 있을까?
그 핵심은 객체 정렬(Object Alignment)에 있다.
객체 정렬과 인코딩
JVM은 객체를 메모리에 할당할 때 기본적으로 8바이트 단위로 정렬한다. 이로 인해 모든 객체의 주소는 항상 8의 배수가 된다.
포인터에 실제 메모리 주소를 저장하는 대신, "몇 번째 객체인지(상대적 위치)"를 저장한다.
- 계산:
실제 주소 = (포인터 값 << 3)(즉, 포인터 값에 8을 곱함)
이러한 인코딩을 통해 32비트 포인터로 8배 더 넓은 영역인 32GB($4GB * 8)까지 표현할 수 있게 되는 것이다.
3. 실전: 32GB의 경계값 찾기
이론상 32GB이지만, 실제로 UseCompressedOops 기능이 꺼지는 지점은 이보다 살짝 아래이다.
JVM이 사용하는 예약 영역이나 시스템 환경에 따라 경계값이 달라지기 때문
엘라스틱서치(Elasticsearch) 가이드에 따르면, 아래와 같은 명령어로 본인의 환경에서 Compressed OOPs가 적용되는 정확한 임계값을 확인 할 수 있다.
$ java -Xmx32736m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
bool UseCompressedOops := true
$ java -Xmx32737m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
bool UseCompressedOops = false
위 테스트 결과에서는 32,736MB가 마법이 풀리기 전 마지막 경계값이 된다.
4. Zero-based Compressed OOPs의 이점
주소 인코딩 시 시작 주소가 0부터 시작할 수 있다면(Zero-based), 복호화 과정에서 시작 주소를 더하는 연산을 생략할 수 있어 성능이 더욱 최적화된다.
성능에 민감한 애플리케이션이라면 Zero-based Compressed OOPs가 적용되는 범위 내로 힙 크기를 설정하는 것이 유리하다.
결론
메모리가 64GB인 서버라고 해서 무턱대고 힙을 40GB로 잡는 것은 오히려 독이 될 수 있다.
32비트 포인터의 효율을 잃어버리고 64비트 포인터를 쓰게 되면서 발생하는 오버헤드가 더 크기 때문
