1. Resource Limit
- 시스템에서 프로세스가 사용할 수 있는 여러 자원의 한계점을 설정하는 방법
- 설정하는 방법은 OS마다 상이하며 여기서는 mac os, linux 기준으로 설명
- 시스템 리소스는 제한된 자원인데 resource limit 설정 시 시스템 관리자가 시스템 리소스를 보호하고 용도에 맞게 분배 가능
- 이를 통해 Elasticsearch의 안정성과 성능을 보장
1.1 Resource Limit 적용 방법
- $ulimit: Unix 및 Unix 계열 운영 체제에서 사용자 별로 시스템 리소스 제한을 임시로 설정하고 조회하는 명령어로 적용 시 현재 세션 동안에만 유효하며, 세션이 종료되면 설정이 사라짐
설정을 영구적으로 적용하려면 /etc/security/limits.conf 파일을 수정해 Soft Limit 혹은 Hard Limit을 적용해야 함
- Soft Limit: 사용자가 현재 세션 내에서 변경할 수 있는 제한이며 보통 경고 임계값으로 사용되며, 해당 값을 초과하면 경고 메시지가 출력될 수 있지만 시스템은 계속 작동할 수 있음
- Hard Limit: 시스템 전체에서 강제하는 최대 제한이며 해당 값은 사용자가 변경할 수 없으며, root 관리자만 설정할 수 있음, hard limit을 초과하면 시스템이 요청을 거부하거나 프로세스를 중단
1.2 Resource Limit 항목 설명
1.2.1 File Descriptors
- 파일 디스크립터는 파일이나 소켓 등의 리소스를 참조하는 식별자
- Apache Lucene의 세그먼트는 굉장히 많은 파일로 구성되어 있기 때문에 Elasticsearch node는 굉장히 많은 파일을 접근함
- 인덱스 내에는 많은 세그먼트가 존재
- file descriptors가 적으면 접근했지만 파일을 못 여는 케이스가 발생할 수도 있음
- 권장하는 값은 65536
- 주의: 충분한 파일 디스크립터를 설정하지 않으면 "Too many open files" 같은 오류가 발생하여 애플리케이션이 제대로 작동하지 않을 수 있음
1.2.2 Core File Size
- 프로세스가 비정상 종료될 때 생성되는 코어 덤프 파일의 최대 크기를 설정
- 코어 덤프 파일은 디버깅에 유용
1.2.3 CPU Time
- 프로세스가 사용할 수 있는 CPU 시간의 최댓값을 설정
- 특정 프로세스가 과도하게 CPU 자원을 사용하는 것을 방지하기 위한 설정
1.2.4 Data Segment Size
- 프로세스의 데이터 영역의 최대 크기를 설정
- 힙 메모리의 크기를 제한하는 데 사용
1.2.5 Stack Size
- 스택은 함수 호출 시 로컬 변수와 함수 호출 정보를 저장하는 메모리 영역
- 스택 크기를 적절히 설정하지 않으면 스택 오버플로우가 발생할 수 있음
2. Disable Swapping
- Elasticsearch는 성능 최적화와 데이터 무결성을 위해 메모리 관리가 매우 중요
- swap memory를 사용하면 성능 저하와 가비지 컬렉션 지연 등의 문제가 발생할 수 있기 때문에, Elasticsearch는 swap 사용을 최대한 피하는 것을 권장
- Elasticsearch는 많은 랜덤 접근을 수행하는데 디스크에서의 랜덤 I/O는 매우 느리기 때문에, 스왑이 발생하면 검색 및 색인 작업이 느려짐
- swap이 발생하면 GC가 자주 발생하고, 디스크 접근이 많아지면서 GC 시간도 크게 증가
- 스왑을 사용하는 대신 메모리가 부족할 때 OutOfMemoryError가 발생하여 노드가 내려갈 수 있으며 이는 클러스터의 가용성을 저하시킬 수 있음
- Elasticsearch는 실시간 검색을 제공하기 위해 메모리를 적극적으로 활용하며 swap이 발생하면 검색 쿼리의 응답 시간이 증가됨
2.1 Swap Memory
- OS에서 메모리를 관리하는 기술 중 하나로 일반적으로 RAM보다 많은 메모리를 필요로 할 때 사용
- 가상 메모리 혹은 페이징 공간으로도 알려진 swap 공간은 일시적으로 빌활성 또는 덜 자주 사용되는 메모리 페이지를 RAM에서 하드 디스크의 지정된 영역으로 이동할 수 있는 OS의 기능
2.2 Thrashing
- 컴퓨터 시스템에서 메모리 관리가 비효율적으로 이루어져 시스템 성능이 극도로 저하되는 현상
- 주로 가상 메모리 시스템에서 발생하며, 과도한 페이지 교체가 일어날 때 발생
- 프로세스들이 필요한 페이지가 물리 메모리에 없는 경우, 페이지 폴트가 발생
- 페이지 폴트가 자주 발생하면, 시스템은 디스크 I/O를 통해 필요한 페이지를 로드해야 하고 이 과정이 반복되면 성능 저하 발생
2.3 Disabling Swapping 방법
2.3.1 Swap 메모리 비활성
- 임시적인 방법: $sudo swapoff -a
- 영구적인 방법: /etc/fstab.conf 파일에서 swap이라는 단어가 있는 모든 라인 주석 처리
2.3.2 Swappiness 설정 (Linux, MacOS)
- 시스템에서 swap 사용에 대한 가중치를 결정하는 값 중 하나로 swap 공간을 어떻게 활용할지에 대한 정책을 제어
- vm.swapiness 옵션은 [0, 100] 범위에서 설정할 수 있음
임시적인 방법
$ sudo sysctl -w vm.swappiness=1
$ sysctl vm.swappiness영구적인 방법
$ vi/etc/sysctl.conf > vm.swappiness = 1
$ :wq2.3.3 Memory Lock
- bootstrap.memory_lock: Elasticsearch 설정 중 하나로 Elasticsearch 프로세스의 힙 메모리를 잠그는 역할
- 메모리를 잠그면 OS가 해당 메모리 페이지를 swap 하지 않도록 하여 Elasticsearch 성능을 향상하는데 도움이 됨
# allow user 'elasticsearch' mlockall // 권한 부여 후
/etc/security/limits.conf 파일에서 다음과 같이 설정
elasticsearch soft memlock unlimited
elasticsearch hard memlock unlimited3. Memory Mapping
- Memory Mapping은 파일을 프로세스의 메모리에 매핑하는 것
- 프로세스에 전달할 데이터를 저장한 파일을 직접 프로세스의 가상 주소 공간으로 매핑
3.1 Memory Mapped Files
- 메모리 매핑 파일은 파일을 디스크에서 메모리에 직접 매핑하여 파일의 내용을 메모리처럼 접근할 수 있게 하는 방법
- 이 방식은 대량의 데이터를 효율적으로 처리할 수 있게 해주며, 파일 I/O 성능을 크게 향상함
- Elasticsearch는 색인(index)과 검색(search) 작업에서 Lucene을 사용하며, Lucene은 색인 데이터를 저장할 때 메모리 매핑 파일을 생성하며 이러한 파일 매핑은 성능을 높이고 검색 속도를 빠르게 하는 데 중요한 역할을 수행
3.2 max_map_count 설정이 필요한 이유
- max_map_count는 Linux 커널 파라미터로, 시스템에서 허용하는 최대 메모리 매핑 영역의 수를 지정하며 default 값은 상당히 낮게 설정되어 있음
- 그러나 Elasticsearch는 여러 색인과 샤드를 관리하기 위해 다수의 메모리 매핑 파일을 사용하므로, 기본값으로는 충분하지 않을 수 있음
- Elasticsearch 클러스터에서 색인과 샤드의 수가 증가할수록 필요한 메모리 매핑 파일의 수도 증가하며 max_map_count 값이 낮으면, 색인 및 샤드 수가 늘어날 때 문제가 발생할 수 있음
- 메모리 매핑 파일은 디스크 I/O를 줄이고 성능을 최적화하며 적절한 max_map_count 설정이 없다면, Elasticsearch는 메모리 매핑 파일을 충분히 활용하지 못해 성능 저하가 발생할 수 있음
- 낮은 max_map_count 설정은 시스템 리소스 부족으로 인한 예기치 않은 오류를 초래할 수 있으며 Elasticsearch 노드의 비정상 종료나 데이터 손상을 유발할 수 있음
3.3 max_map_count 설정 방법
임시적인 방법
$ sudo sysctl -w vm.max_map_count=262144 # es에서 권장하는 설정
$ sysctl vm.max_map_count영구적인 방법
/etc/sysctl.conf 파일에서 다음과 같이 설정
vm.max_map_count=14. TCP retransmission timeout
- TCP 프토콜이 패킷을 다시 전송하기 전에 대기하는 시간을 결정
- 패킷을 보낸 후 응답이 올 때까지 기다리는 시간
4.1 Elasticsearch에 TCP Retransmission timeout 설정이 필요한 이유
- 클러스터 노드 간의 통신 안정성과 성능을 보장하기 위해 설정
- TCP RTO는 데이터 패킷이 손실되거나 네트워크 지연이 발생했을 때 재전송을 시도하기까지의 시간을 결정하는 중요한 네트워크 파라미터
- Elasticsearch는 분산 시스템이므로 노드 간의 네트워크 통신이 원활하게 이루어져야 하며, RTO 설정은 이에 중요한 역할을 수행
- 클러스터 내 노드 간의 통신은 검색 쿼리 처리, 색인 데이터 복제, 클러스터 상태 업데이트 등에 필수적이며 TCP 재전송 타임아웃이 너무 길게 설정되어 있으면, 패킷 손실 시 재전송이 지연되어 전체 성능이 저하될 수 있음
- 데이터 전송 중 패킷이 손실되면, 재전송 타임아웃이 빠르게 설정되어야 데이터 전송이 신속하게 재개될 수 있으며 이는 특히 대용량 데이터를 전송할 때 중요함, RTO가 너무 길면 데이터 전송 속도가 느려지고, 시스템 응답 시간이 증가할 수 있음
- Elasticsearch는 높은 가용성과 내결함성을 제공하기 위해 데이터 복제를 수행하는데 TCP RTO 설정이 적절하지 않으면, 네트워크 장애 발생 시 복제 작업이 지연되거나 실패할 수 있음
4.2 TCP Retransmission timeout 적용 방법
임시적인 방법
$ sudo sysctl -w net.ipv4.tcp_retries2=5영구적인 방법
/etc/sysctl.conf 파일에 다음과 같이 설정
net.ipv4.tcp_retries2=5
* 주의: sysctl.conf 파일에 설정 시 es 외 tcp 사용하는 다른 프로세스에도 영향을 끼치기 때문에 충분한 고려 필요
5. 힙 메모리 설정
- Elasticsearch는 Java로 작성되어 있어 JVM 힙 메모리 설정이 중요하며 힙 메모리는 Elasticsearch의 데이터 구조, 캐시, 필터 등의 데이터가 저장되는 공간
- Elasticsearch의 힙 메모리 크기는 OS와 파일 시스템 캐시에 충분한 메모리를 남겨두기 위해서 전체 시스템 메모리의 50% 이하로 설정하는 것이 좋음
- -Xms와 -Xmx 값을 동일하게 설정하여 힙 메모리 크기를 고정하는 것을 권장하며 이는 JVM의 가비지 컬렉션 성능을 최적화하는 데 도움이 됨
- JVM의 컴프레스드 OOPS(Ordinary Object Pointers) 기능을 사용하기 위해 힙 메모리는 32GB를 넘지 않도록 설정
- 32GB를 초과하면 메모리 주소 공간이 비효율적으로 사용됨
5.1 힙 메모리 크기 설정 방법
- 힙 메모리 크기는 jvm.options 파일에서 설정할 수 있으며 해당 파일은 Elasticsearch 설치 디렉토리의 config 폴더에 위치
- <Elasticsearch_Home>/config/jvm.options
-Xms32g
-Xmx32g참고
- 패스트 캠퍼스 - 고성능 검색 엔진 구축으로 한 번에 끝내는 Elasticsearch
반응형
'Elastic Search' 카테고리의 다른 글
| [Elasticsearch] Elasticsearch 구성할 때 유의할 점 (0) | 2024.07.19 |
|---|---|
| [Elasticsearch] 색인 (0) | 2024.06.28 |
| [Elasticsearch] 검색 (0) | 2024.06.28 |
| [Elasticsearch] ILM (0) | 2024.06.27 |
| [ELK] Beats 정리 (0) | 2024.06.25 |