ElasticSearch Heap 메모리 설정

※ 권장 메모리 할당량
ElasticSearch(이하 ES)의 힙 사이즈는 전체 서버가 가진 메모리의 반을 설정하는 것을 권장.
만약 서버가 64GB 이상의 메모리를 가지고 있다 하더라도 30.5GB이상을 ES에 할당하는 것은 권장하지 않음.
ex) 32GB 메모리를 가진 서버 : ES에 16GB 할당
64GB 메모리를 가진 서버 : ES에 30.5GB 할당
128GB 메모리를 가진 서버 : ES에 30.5GB 할당

 

---

Memory Swapping 기능 비활성화

swap off

# 일시 적용. reboot하면 원상복구 됨 swapoff -a    # 영구 적용 vi /etc/fstab # swap이란 단어를 포함하고 있는 라인 주석처리 후 저장    # vm.swappiness 설정 확인 sysctl -a |grep swappiness    # grep되는 결과가 없거나 1이 아닌 값으로 설정되어 있다면 설정 수정 vi /etc/sysctl.conf vm.swappiness=1    # 추가 후 sysctl -p

vm.swappiness 설정

vm.swappiness 설정은 swap 사용의 적극성 혹은 활용 수준을 정하는 커널 속성

0으로 설정하면 사용안함, 1은 최소로 사용, 100에 가까울 수록 적극적으로 swap 활용

위에서 0으로 설정하지 않고 1로 설정하는 이유는 0으로 설정 시 OOM Killer가 swap을 사용하려고 시도하는 어플리케이션을 바로 kill 시켜버릴수도 있기 때문

 

memory lock

elasticsearch.yml

# ES 설정값 수정 vi /etc/elasticsearch/elasticsearch.yml    # 버전에 따라 프로퍼티 이름이 다름 # ES 2.X 인 경우 bootstrap.mlockall: true   # ES 5.X 인 경우 bootstrap.memory_lock: true

 

Zero-Based Compressed Oops (Ordinary Object Pointers)

• 권장 메모리 할당량에서 30.5GB 이상으로 설정하지 말라고 했던 것의 연장선 입니다.
• JAVA는 64bit의 OS라 할지라도 4GB이하의 heap을 가지고 JVM을 띄우며 32bit의 oops를 그대로 따라가도록 설계되어 있음
  • 4GB가 넘어가는 영역에 대해서는 compressed oops라는 기법을 사용(포인터가 실제 오브젝트가 들어있는 메모리 주소값을 가르키는 것이 아니고 8byte단위로 나눠놓은 offset을 가르킴 - JAVA가 사용하는 메모리 스키마가 8byte의 구조를 가지고 있음)
  • 이렇게 되면 2의 32승bit(=4GB)을 표현할 수 있는 32bit oop를 이용하여 실제로는 8배 많은 32GB의 주소값까지 표현할 수 있게 됨
  • 8byte단위로 건너 뛰면서 mapping을 해놓으면 좌로 3번 시프트(<< 3)해 주는 연산만으로 원래 가르키고자 했던 주소값을 정확히 가르킬수 있게 됨
• 이렇게 되기 위해서는 한가지 필요충분조건이 필요
  • 메모리 주소의 시작점이 0부터 시작해야한다는 조건
  • 이 조건이 충족되지 않으면 Non-Zero based Compressed oops로 동작을 하게 되고 좌로 3번 시프트(<< 3) 해준 이후에 시작점만큼 + 해주는 연산이 추가로 들어가야 되서 메모리의 크기가 큰 경우 성능에 영향을 끼침
• 자세한 내용은 링크 참조
  • http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html
  • https://wiki.openjdk.java.net/display/HotSpot/CompressedOops

ES에 할당할 수 있는 메모리 크기 구하기

ES메모리 할당

서버의 메모리가 63GB 미만이라면 => 서버의 메모리의 반

서버의 메모리가 63GB 이상이라면 => 내 서버에서 Zero based 모드로 Compressed oops를 사용할 수 있는 임계치

 

임계치 알아보는 방법

# 테스트한 서버는 64GB의 메모리를 가진 서버입니다. # 32GB 할당하는 경우 확인 java -Xmx32G -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode 2>/dev/null |grep Compressed |grep Oops bool PrintCompressedOopsMode                  := true                                {diagnostic} bool UseCompressedOops                         = false                               {lp64_product}     # bool UseCompressedOops = false 임을 확인할 수 있음. 사용하면 안 됨       # 31GB 할당하는 경우 확인 java -Xmx31G -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode 2>/dev/null |grep Compressed |grep Oops heap address: 0x00007f9348800000, size: 31744 MB, Compressed Oops mode: Non-zero based:0x00007f93487ff000, Oop shift amount: 3 bool PrintCompressedOopsMode                  := true                                {diagnostic} bool UseCompressedOops                        := true    # 31GB는 UseCompressedOops = true 지만 Compressed Oops mode 가 Non-zero based 인 것을 확인할 수 있음. 사용하면 안 됨.    # 30GB 할당하는 경우 확인 java -Xmx30G -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode 2>/dev/null |grep Compressed |grep Oops heap address: 0x0000000080000000, size: 30720 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 bool PrintCompressedOopsMode                  := true                                {diagnostic} bool UseCompressedOops                        := true          #  CompressedOops 도 사용하고 Compressed Oops mode가 Zero based 인 것을 확인할 수 있음. 30GB가 임계치임을 확인

 

추가 Tip

30GB로 운영하는데 CPU도 별로 많이 사용안하고 메모리도 여유있는 것으로 확인되면 FullGC 시간을 줄이기 위해 Heap을 24GB정도로 내려서 사용하는 것도 고려해볼만한 사항.

운영 환경에서 최적의 Heap메모리를 적용하기 위해서는 일정기간 트렌딩을 살펴보고 결정하는 것이 좋음