[ElasticSearch] JVM: Heap size

엘라스틱서치가 실행되면 엘라스틱서치와 루씬 둘 다 JVM 위에서 함께 동작한다.
따라서 운영체제와 엘라스틱서치에 메모리를 잘 분배하여 할당해야한다.

루씬

루씬은 운영체제의 시스템 캐시를 통해 메모리를 활용함
시스템 캐시는 운영체제가 가지고 있는 메모리 공간
실시간 검색을 지원하기 위해서는 루씬이 최대한 많은 시스템 캐시를 확보하도록 지원해야함

엘라스틱서치

엘레스틱서치 힙에 메모리를 할당하여 메모리 활용

엘라스틱서치 인스턴스의 힙 크기 확인

$ vi jvm.options

• JVM이 실행될 때 기본적으로 Xms에 설정된 힙 크기로 동작
• 힙이 부족하다고 판단되면 Xmx에 설정된 힙 크기까지 자동으로 확장
• 보통 엘라스틱서치는 할당된 메모리를 최대로 쓰기 때문에 처음부터 Xms와 Xmx를 같게 설정해주는 것이 좋음
• Xms에서 Xmx로 전환될 때도 비용이 크기 때문

적절한 힙 크기

• 물리 메모리의 50% -> 운영체제
• 나머지 50% -> 엘라스틱서치

그럼 엘라스틱서치에 할당된 나머지 50%의 메모리를 하나의 엘라스틱서치 인스턴스 힙에 몰빵하는게 좋을까?
아니다!!

1. 엘라스틱서치 힙 크기는 32GB로 제한하는 것이 좋음

OOP

JVM에서 힙 영역에 생성된 객체에 접근하기 위해 포인터의 주소를 저장하는 특수한 자료구조
32비트에서는 사용 가능한 메모리 공간이 너무 적고
64비트에서는 메모리 낭비가 심함
ex) 64비트의 OOP에서는 2^64까지의 주소를 가리킬 수 있음 -> 2^64까지의 메모리 공간 활용

Compressed OOP

포인터가 객체의 정확한 메모리 주소를 가리키게 하는 것이 아니라 상대적인 오브젝트 오프셋을 가리키도록 변형한 방식.
객체의 최소 단위: 8비트
메모리 낭비를 줄이고, 사용 가능한 메모리 공간을 늘릴 수 있음
ex) 32비트의 Compressed OOP에서는 (2^64)*8 까지의 주소를 가리킬 수 있음 -> (2^64)*8까지의 메모리 공간 활용

OOP 동작 방식

• 32GB 이하에서는 32비트 Compressed OOP로 동작
• 32GB 초과 시 일반 64비트 OOP로 자동 변환 -> Compressed OOP의 이점을 잃음 -> 메모리 낭비, GC에 부담

따라서 32GB를 초과해서 힙에 할당할 바에
힙 크기를 32GB로 제한하고 하나의 물리적인 서버에 다수의 엘라스틱서치 인스턴스를 생성하는 편이 나음

2. 상황에 따른 적절한 분배 필요

(1) 적절한 성능의 서버를 가지고 있을 때

총 물리 메모리: 64GB
운영체제 할당: 32GB
엘라스틱서치 인스턴스 수: 1개(32GB)

(2) 고성능 서버를 가지고 있을 때

총 물리 메모리: 128GB
운영체제 할당: 64GB
엘라스틱서치 인스턴스 수: 2개(32GB)

(3) 전문(Full Text) 검색을 주 목적으로 엘라스틱 서치를 사용하는 경우

총 물리 메모리: 128GB
운영체제 할당: 96GB
엘라스틱서치 인스턴스 수: 1개(32GB)

(4) 일반적인 데이터 필드(Not Analyzed)에서 정렬/집계 작업을 많이 수행하는 경우

총 물리 메모리: 128GB
운영체제 할당: 64GB
엘라스틱서치 인스턴스 수: 2개(32GB)

---

References

엘라스틱서치 실무가이드(위키북스)