애플리케이션에서 튜닝 가능한 리소스
1) ulimit
- ulimit 명령어는 애플리케이션이 실행될 때 얼마큼의 리소스를 할당받을 수 있는지 리소스 관리를 수행한다.
- 애플리케이션이 생성될 때 받을 수 있는 리소스 최댓값이 관리된다.
- ulimit -a 명령어를 사용해 한 프로세스가 가질 수 있는 리소스의 정보를 확인할 수 있다.
2) sysctl
- 리눅스 내부에 존재하는 커널의 파라미터를 조절할 수 있도록 설정 값을 제공한다.
- 커널 레벨의 다양한 파라미터 확인 가능
- 애플리케이션이 실행될 때 생성되는 리소스 정보를 커널 레벨까지 자세히 제공한다.
3) 실행 중인 애플리케이션 리소스 확인
- PID를 이용해 실행 중인 애플리케이션의 리소스 제한 값을 조회할 수 있다
- cat /proc/{$pid}/limits
- 엘라스틱서치가 단독으로 사용되는 경우에는 ulimit 명령어나 sysctl 명령어를 사용해 엘라스틱서치가 리소스를 독점해서 사용할 수 있도록 설정할 수 있다.
ulimit 명령어를 이용한 유저 레벨의 튜닝
ulimit 값을 변경하는 작업은 신중하게 변경해야 하며, 해당 값은 운영체제에서 실행되는 모든 애플리케이션에 적용되기 때문에 각 항목이 의미하는 바가 무엇인지 이해하고 변경해야 한다.(잘못 변경 시, 장애 발생 위험이 있다.
ulimit 명령어
ulimit -a- 운영체제에 설정된 전체 리소스 제한 값을 조회할 수 있다.
| -c | core | 생성할 수 있는 core dump 파일의 최대 크기 (바이트 단위) |
| -d | data | 프로세스의 데이터 세그먼트 최대 크기 |
| -e | nice | 프로세스의 nice 값 (스케줄링 우선순위) 최대값 |
| -f | fsize | 셸이 생성할 수 있는 파일의 최대 크기 |
| -) | sigpending | 보류 중인 시그널의 최대 수 (한 사용자가 대기시킬 수 있는) |
| -l | memlock | 물리 메모리를 잠글 수 있는 최대 용량 (스와핑 방지용) |
| -m | rss | Resident Set Size (RSS): 물리 메모리에 올릴 수 있는 최대 메모리 |
| -n | nofile | 생성할 수 있는 파일 디스크립터의 최대 수 |
| -p | pipe size | 파이프의 크기 (512바이트 블록 단위, 설정 불가일 수 있음) |
| -q | msgqueue | POSIX 메시지 큐의 최대 바이트 수 |
| -r | rtprio | 실시간 스케줄링에서 우선순위 최대값 |
| -s | stack | 프로세스 스택 메모리의 최대 크기 |
| -t | cpu | 프로세스 당 CPU 사용 시간의 최대값 (초 단위) |
| -u | nproc | 한 사용자가 생성할 수 있는 프로세스의 최대 수 |
| -v | as | 생성할 수 있는 가상 메모리의 최대 크기 |
| -x | locks | 생성할 수 있는 파일 락의 최대 수 |
| -b | 소켓 버퍼 최댓값 | |
| -T | 생성할 수 있는 스레드의 최대 갯수 |
소프트 설정과 하드 설정
unlimit는 내부적으로 소프트 설정과 하드 설정을 가지고 있다. 이렇게 이중으로 리소스를 제한하는 이유는 모든 프로세스가 항상 최댓값으로 설정된 리소스를 할당 받을 경우 리소스 낭비가 심해질 수 있기 때문이다.
1) 소프트 설정
ulimit -Sa- 프로세스가 실행될 때 최초로 할당받는 값
2) 하드 설정
ulimit -Ha- 운영 중에 리소스 한계에 도달할 경우 추가적으로 할당받을 수 있는 값
엘라스틱서치의 경우 많은 리소스를 사용하기 때문에 소프트 설정과 하드 설정 값을 동일하게 설정하는 것이 좋은데, 하드 설정 값에 따른 리소스를 할당받는 경우에도 많은 비용이 발생하기 때문이다.
ulimit 영구 설정
vi /etc/security/limits.conf- 리부팅되더라도 설정 내역이 유지되도록 영구적으로 저장하는 것이 필요한데, 리눅스는 /etc/security/limits.conf 파일을 제공한다.
- 시스템이 리부팅될 때 해당 파일을 참고해 설정한다.
- 소프트 설정의 경우 기본 할당되는 리소스의 제한 값이고, 하드 설정의 경우 최댓값이다.
- 소프트 설정은 하드 설정 값을 넘어갈 수 없기에 주의 필요
- 일부 ulimit 옵션으로 제공되지 않는 항목들은 해당 파일을 수정해서 수동으로 바꿔주어야 한다.
Sysctl 명령어를 이용한 커널 레벨의 튜닝
sysctl 명령어는 커넬에서 제공하는 다양한 파라미터 정보를 제공하며, 수정할 수 있다. 각 항목하나하나가 커널에서 사용 중인 중요한 정보로 잘못 수정할 경우 운영체제 전체가 심각한 불능상태에 빠질 수 있어 주의가 필요하다.
sysctl
/sbin/sysctl -a- 운영체제에 설정된 리소스 제한 값을 조회
sysctl -w 파라미터 명 = 파라미터 값- 운영체제에 설정된 리소스 제한 값을 수정
sysctl 영구 설정
vi /etc/sysctl.conf- /etc/sysctl.conf 파일을 수정하면 시스템이 리부팅되더라도 설정 내역이 그대로 유지된다.
엘라스틱서치 노드 레벨의 튜닝
Max Open File 한계 설정
ulimit -n PID // Max Open File 한계 설정
// vi /etc/security/limits.conf // 영구 설정
// ulimit -a //확인(체크용)- 엘라스틱서치에서 추가로 리소스를 사용하기 위해 운영체제에 리소스 할당을 요청했을 때, ulimit 제한에 걸릴 경우 "Too Many open Files" 에러를 내며 장애를 발생시킨다.
- 엘라스틱서치 노드는 많은 수의 소켓을 사용해 클라이언트와 통신하며, 내부 루씬은 색인 데이터를 관리하기 위해 많은 수의 파일을 사용하는데 이런 작업 모두 파일 디스크립터가 사용되기 때문에 많은 수의 파일을 생성할 수 있어야 한다.
- 리눅스에서 기본으로 제공하는 max open file 설정 값은 작기 때문에 65,536 개 이상의 큰 값으로 변경하는 것이 좋다.
- 커널에서도 내부적으로 설정 가능한 파일 갯수를 관리하고 있어 이를 넘어갈 경우 오류가 발생한다.(커널레벨에서 증설이 필요)
- cat /proc/sys/fs/file-max
- sysctlfs.file-max
GET _nodes/stats/process- _nodes API를 이용해 노드의 각종 정보를 확인할 수 있다.
Max Thread 한계 설정
ulimit -u 81920 //thread 갯수 변경
//ulimit -a //확인- 엘라스틱서치는 빠른 처리를 위해 대량의 스레드를 사용하며, 이를 관리하는 스레드 풀을 적극 사용한다
- 엘라스틱서치가 관리하는 스레드풀 내부의 스레드 갯수를 사용자가 직접 설정할 수 있지만, 엘라스틱서치는 물리적인 CPU를 기반해 최적의 스레드 수를 자동으로 계산해 설정해 주기 떄문에 엘라스틱서치에 위임하는 것이 좋다.
엘라스틱서치 스레드 풀설명주요 사용 API / 동작
https://www.elastic.co/docs/reference/elasticsearch/configuration-reference/thread-pool-settings
Thread pool settings | Reference
A node uses several thread pools to manage memory consumption. Queues associated with many of the thread pools enable pending requests to be held instead...
www.elastic.co
| generic | 일반적인 비동기 작업용(메타데이터 업데이트, 클러스터 상태 변경 등) | 클러스터 관리, 내부 이벤트 |
| index | 색인(indexing) 작업 처리용 | index, update, delete 단건 요청 |
| bulk | 대량 색인(bulk indexing) 작업 처리용 | _bulk API |
| search | 검색 및 집계 처리용 | _search, _count, _msearch, _terms, _aggs 등 |
| get | 문서 단건 조회(GET 요청) 처리 | _doc/{id}, _get |
| refresh | 인덱스 세그먼트 refresh 요청 처리 | refresh interval, 강제 refresh |
| warmer | 세그먼트 warming (쿼리 캐시 사전 준비) | 인덱스 segment warming (ES 7 이후 거의 사용 안 함) |
| listener | 비동기 listener callback 처리 | Java High Level REST Client, async 요청 콜백 |
| snapshot | 스냅샷 생성 및 복원 작업 | _snapshot, _restore |
| management | 내부 관리 작업 (GC 모니터링, 클러스터 헬스 등) | 시스템 관리용 |
| flush | flush 요청(트랜잭션 로그 flush 등) | 자동 flush, 수동 flush |
| force_merge | 세그먼트 병합(Force merge) | _forcemerge API |
| analyze | _analyze API 호출 시 분석 처리 | _analyze |
| ml | 머신러닝(Elastic ML 기능) 관련 작업 | Elastic ML job 실행 시 |
| write (ES 7.6 이후 추가) | write (index, delete) 공통 처리용 | index, bulk, delete 등 통합됨 |
GET _nodes?filter_path=**.thread_pool
{
}- _nodes API를 이용해 스레드풀 관련 정보만 조회할 수도 있다.
- 실제 스레드의 종류 및 각 스레드 풀에 생성한 스레드 개수와 버퍼 용도로 사용한 큐의 크기 정보를 볼 수 있다.
네트워크 설정
- 네트워크 설정은 동시 사용자가 적거나 네트워크 트래픽이 적을 경우 큰 성능 향상을 느낄 수 없다.
- 톰캣이나 제티 같은 WAS 기반의 애플리케이션 설정을 그대로 적용하는 것도 나쁘지 않은 선택이다.(최적화가 되어 있다는 기준)
- sysctl 명령어를 이용해 운영체제 수준의 네트워크도 설정해 주는 것이 좋다.
네트워크 관련 커널 파라미터
net.core.somaxconn = 4096
net.core.netdev_max_backlog = 16000
net.core.rmem_max = 4194304
net.core.wmem_max = 4194304
net.ipv4.tcp_max_syn_backlog = 16000
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4. tcp_wmem = 4096 87380 4194304
net.ipv4.tcp_fin_timeout = 12
'Elastic Search' 카테고리의 다른 글
| Ch11. 장애 방지를 위한 실시간 모니터링 - 물리적인 클러스터 상태 정보 조회 (0) | 2025.10.15 |
|---|---|
| Ch11. 장애 방지를 위한 실시간 모니터링 - 클러스터 Health 체크 (0) | 2025.10.15 |
| Ch10. 대용량 처리를 위한 시스템 최적화 - 분산환경에서의 메모리 스와핑 (0) | 2025.10.10 |
| Ch10. 대용량 처리를 위한 시스템 최적화 - 엘라스틱서치와 가상 메모리 (0) | 2025.10.10 |
| Ch10. 대용량 처리를 위한 시스템 최적화 - 힙 크기를 32GB 이하로 유지해야 하는 이유 (0) | 2025.10.10 |