mmap count
기본적으로 자바 기반의 어플리케이션은 가상머신 위에서 돌아가도록 설계가 되어잇으며 JVM을 통해 할당받은 힙 메모리만 사용할 수 있다. 하지만 루씬의 경우 대용량 세그먼트를 생성하고 관리하기 위해 많은 리소스를 필요하다.
루씬은 내부적으로 자바에서 제공하는 NIO 기술을 활용한다고 한다. 이를 통해 운영체제 커널에서 제공하는 mmap 시스템콜을 직접 호출 할 수 있다.
이로 인해 커널 레벨의 파일 시스템 캐시를 사용할 수 있다.
vm.max_map_count는 운영체제가 응용프로그램이 생성할 수 있는 최대 mmap 파일의 수를 지정한다. 엘라스틱서치는 파일시스템 캐시를 적극 활용하기때문에 이 값을 가능한 크게 설정해주어야 한다.
swap memory
ES는 메모리에 많은양의 데이터를 올려놓고 searching, indexing 등의 작업을 하기 때문에 swap을 켜 놓으면 disk로 내려서 작업이 되어 버리는 순간 성능에 치명적인 악영향을 끼칠수 있다.
tcp retry
대부분의 Linux 배포판은 기본적으로 손실된 패킷을 15번 재전송합니다. 재전송은 기하급수적으로 중단되므로 이러한 15개의 재전송을 완료하는 데 900초 이상이 걸립니다. 이는 Linux가 이 방법으로 네트워크 파티션이나 실패한 노드를 감지하는 데 몇 분이 걸린다는 것을 의미함으로 5번으로 바꿔준다.
TCP retransmission timeout | Elasticsearch Guide [8.6] | Elastic
TCP retransmission timeout | Elasticsearch Guide [8.6] | Elastic
This setting applies to all TCP connections and will affect the reliability of communication with systems other than Elasticsearch clusters too. If your clusters communicate with external systems over a low quality network then you may need to select a hig
www.elastic.co
[/etc/sysctl.conf]
vm.max_map_count = 262144
vm.swappiness = 1
net.ipv4.tcp_retries2 = 5
open files
루씬은 색인 파일을 효율적으로 관리하기 위해 매우 많은 수의 파일을 생성하고 사용한다. 이 때 운영체제의 파일디스크립터(fd)가 사용되기때문에 엘라스틱서치는 일반적인 애플리케이션보다 훨씬 많은 수의 파일을 사용한다.
리눅스가 기본으로 제공하는 최대 open file 수는 작기 때문에 최소 65,536 이상으로 설정해주어야 한다.
Max Thread
엘라스틱서치는 필요에 따라 유동적으로 스레드를 생성해서 사용한다. 이 때 엘라스틱서치가 필요한 만큼의 충분한 스레드를 생성할 수 있도록 하기 위해 최대 스레드 수의 제한을 적절한 크기로 설정해주어야한다.
[/etc/security/limits.conf]
elastic soft nofile 65536
elastic hard nofile 65536
elastic soft nproc 4096
elastic hard nproc 4096
'검색엔진 > ElasticSearch' 카테고리의 다른 글
ElasticSearch vs Solr (0) | 2022.04.29 |
---|---|
인덱싱 성능 최적화 (0) | 2022.04.05 |
ElasticSearch 색인, 검색 노드 나누기 (0) | 2022.03.23 |
ElasticSearch - Rolling Restart (0) | 2022.03.22 |
ElasticSearch - Full-cluster Restart (0) | 2022.03.21 |