Elasticsearch 성능을 위한 JVM 튜닝: 힙 및 가비지 컬렉션 팁

Elasticsearch는 JVM에서 실행되므로 힙과 가비지 컬렉션이 중요합니다. 하지만 클러스터가 느린 경우 JVM 튜닝부터 시작하지는 않을 것입니다. 먼저 샤드 수, 쿼리 형태, 색인 압력, 디스크 지연 시간, 노드가 단순히 규모가 부족한지 확인하세요. JVM 설정은 잘못된 값이 건강한 클러스터를 불안정하게 만들 수 있기 때문에 중요합니다. 이는 잘못된 인덱스 설계나 과부하된 하드웨어를 우회하는 지름길이 아닙니다.

이 가이드는 일상 운영에서 여전히 유용한 Elasticsearch JVM 튜닝에 초점을 맞춥니다: 힙 크기 조정, 가비지 컬렉션 증상, 메모리 압력, 그리고 Java가 실제로 문제인지 알려주는 실용적인 점검.

Elasticsearch 메모리 요구 사항 이해

Elasticsearch는 힙 메모리와 오프-힙 메모리라는 두 가지 주요 영역에 메모리가 필요합니다. 적절한 튜닝은 힙을 올바르게 설정하고 운영 체제가 오프-힙 요구 사항을 위해 충분한 물리적 메모리를 남겨두도록 하는 것입니다.

1. 힙 메모리 할당 (`ES_JAVA_OPTS`)

힙은 Elasticsearch 객체, 인덱스, 샤드 및 캐시가 상주하는 곳입니다. 구성할 가장 중요한 설정입니다.

힙 크기 설정

Elasticsearch는 초기 힙 크기(-Xms)를 최대 힙 크기(-Xmx)와 동일하게 설정할 것을 강력히 권장합니다. 이렇게 하면 JVM이 힙을 동적으로 크기 조정하는 것을 방지하여 눈에 띄는 성능 일시 중지를 유발할 수 있습니다.

모범 사례: 50% 규칙

물리적 RAM의 50% 이상을 Elasticsearch 힙에 할당하지 마십시오. 나머지 메모리는 운영 체제(OS) 파일 시스템 캐시에 매우 중요합니다. OS는 이 캐시를 사용하여 디스크에서 자주 액세스하는 인덱스 데이터(역 인덱스, 저장된 필드)를 저장하며, 이는 디스크에서 읽는 것보다 훨씬 빠릅니다.

권장 사항: 시스템에 64GB RAM이 있는 경우 -Xms 및 -Xmx를 31g 이하로 설정하십시오.

구성 위치

이러한 설정은 일반적으로 Elasticsearch 구성 디렉토리(예: $ES_HOME/config/jvm.options)에 있는 jvm.options 파일이나 설정을 외부에서 관리하려는 경우 환경 변수(예: ES_JAVA_OPTS 사용)를 통해 구성됩니다.

예시 구성 (jvm.options에서):

# 초기 Java 힙 크기 (예: 30 기가바이트)
-Xms30g

# 최대 Java 힙 크기 (-Xms와 일치해야 함)
-Xmx30g

힙 크기 경고: 힙 크기를 31GB(또는 약 32GB) 이상으로 설정하지 마십시오. 64비트 JVM은 약 32GB 미만의 힙에 대해 압축된 객체 포인터(Compressed Oops)를 사용하여 더 메모리 효율적인 객체 레이아웃을 제공하기 때문입니다. 이 임계값을 초과하면 이 효율성 이점이 무효화되는 경우가 많습니다.

2. 오프-힙 메모리 (직접 메모리)

Elasticsearch는 Java 힙 외부의 메모리도 사용합니다. Lucene은 운영 체제 페이지 캐시에 크게 의존하며, Elasticsearch는 네트워크 및 네이티브 작업에 직접 메모리를 사용할 수 있습니다. 대부분의 설치에서 Elastic 문서나 지원 가이드에서 특정 버전과 워크로드에 대해 명시적으로 지시하지 않는 한 -XX:MaxDirectMemorySize를 설정하지 않아야 합니다. 수동 직접 메모리 제한은 너무 낮거나 오래된 가정에 기반한 경우 새로운 실패 모드를 만들 수 있습니다.

가비지 컬렉션(GC) 튜닝

가비지 컬렉션은 JVM이 더 이상 참조되지 않는 객체가 사용하는 메모리를 회수하는 프로세스입니다. Elasticsearch에서 제대로 관리되지 않은 GC는 종종 "stop-the-world" 일시 중지라고 하는 심각한 지연 시간 스파이크를 유발하여 노드 시간 초과 및 불안정성을 초래할 수 있습니다.

올바른 수집기 선택

최신 Elasticsearch 릴리스는 지원되는 JVM 기본값과 함께 제공되며 일반적으로 최신 Java 버전에서 G1GC를 사용합니다. 이러한 기본값을 기준으로 취급하십시오. 로그와 메트릭이 실제 가비지 컬렉션 문제를 보여줄 때만 수집기 설정을 변경하십시오.

G1GC 튜닝 매개변수

G1GC 최적화의 주요 매개변수는 최대 일시 중지 시간 목표를 설정하는 것입니다. 이는 수집기가 메모리를 얼마나 적극적으로 정리해야 하는지 알려줍니다.

예시 G1GC 구성:

# 예시 전용: 버전이 지원하고 기본 동작이 문제라는 증거가 없는 한 GC 플래그를 추가하지 마십시오.
-XX:MaxGCPauseMillis=200

GC 활동 모니터링

효과적인 튜닝은 GC가 언제 실행되고 얼마나 오래 걸리는지 알아야 합니다. Elasticsearch를 사용하면 GC 이벤트를 파일에 직접 기록할 수 있으며, 이는 지연 시간 문제를 해결하는 데 필수적입니다.

GC 로깅 활성화:

jvm.options 파일에 다음 플래그를 추가하여 상세 GC 로깅을 활성화하십시오:

# GC 로깅 활성화
-Xlog:gc*:file=logs/gc.log:time,level,tags

# 선택 사항: 로그 회전 크기 지정 (예: 10MB 후 회전)
-Xlog:gc*:file=logs/gc.log:utctime,level,tags:filecount=10,filesize=10m

GCEasy와 같은 도구나 특정 스크립트를 사용하여 결과 gc.log 파일을 분석하여 다음을 식별하십시오:

빈도: GC가 얼마나 자주 실행되는지.
지속 시간: 일시 중지 길이 (Total time for GC in...).
승격 속도: 얼마나 많은 데이터가 오래된 세대로 이동할 만큼 오래 살아남는지.

GC 일시 중지가 MaxGCPauseMillis 목표를 지속적으로 초과하는 경우(예: 자주 500ms 이상 도달), 이는 메모리 압력을 나타냅니다. 해결 방법으로는 힙 크기 증가(RAM이 허용하고 50% 규칙을 준수하는 경우) 또는 객체 변동을 줄이기 위한 인덱싱/쿼리 패턴 최적화가 있습니다.

실용적인 튜닝 워크플로 및 모범 사례

Elasticsearch JVM 설정을 튜닝하려면 이 체계적인 접근 방식을 따르십시오:

1단계: 노드 용량 결정

Elasticsearch 노드를 호스팅하는 시스템에서 사용 가능한 총 물리적 RAM을 식별하십시오.

2단계: 힙 크기 계산

최대 힙 크기를 계산하십시오: 최대 힙 = 물리적 RAM * 0.5 (가장 가까운 안전한 분수로 내림, 일반적으로 1-2GB 여유 버퍼 유지). -Xms 및 -Xmx를 이 값으로 설정하십시오.

3단계: 이유가 없는 한 직접 메모리는 그대로 두십시오.

오래된 블로그 게시물에서 직접 메모리 플래그를 복사하지 마십시오. 먼저 Elasticsearch 버전의 문서와 현재 시작 로그를 확인하십시오.

4단계: GC 구성

-XX:+UseG1GC가 있는지 확인하고 -XX:MaxGCPauseMillis=100과 같은 합리적인 목표를 설정하는 것을 고려하십시오.

5단계: 로깅 활성화 및 모니터링

GC 로깅을 활성화하고 클러스터를 일반적인 프로덕션 부하에서 몇 시간 또는 며칠 동안 실행하십시오. 로그를 검토하십시오.

6단계: 로그 기반 반복

일시 중지가 너무 긴 경우: 인덱싱 부하를 줄이거나, RAM이 허용하면 힙 크기를 약간 늘리고 50% 규칙을 재평가해야 할 수 있습니다.
GC가 매우 자주 실행되지만 일시 중지가 짧은 경우: 힙이 약간 너무 작아 과도한 마이너 컬렉션을 유발하거나 너무 많은 단기 객체를 생성하고 있을 수 있습니다.

샤드 크기 조정 팁: JVM 튜닝은 적절한 인덱싱 전략과 결합될 때 가장 효과적입니다. 과도한 샤딩(너무 많은 작은 샤드)은 JVM이 많은 구조에 걸쳐 방대한 수의 객체를 관리하도록 강제하여 GC 오버헤드를 증가시킵니다. 노드당 오버헤드를 줄이기 위해 더 큰 샤드(예: 10GB ~ 50GB)를 목표로 하십시오.

실제 클러스터에서 힙 압력의 모습

힙 압력은 당직자에게 "힙 압력"이라고 스스로 알리는 경우가 거의 없습니다. 검색 지연 시간 스파이크, 인덱싱 거부, 느린 클러스터 상태 업데이트, 노드 이탈 및 재가입, 또는 트래픽이 최고조에 달할 때까지 괜찮아 보이는 대시보드로 나타납니다. 유용한 신호는 JVM 힙이 상승하고, 가비지 컬렉션이 실행되고, 이후 힙이 건강한 수준으로 돌아오는지 여부입니다.

바쁜 기간 동안 힙이 상승했다가 가비지 컬렉션 후 떨어지면 노드가 단순히 열심히 일하고 있는 것일 수 있습니다. 힙이 상승하고 오래된 세대 컬렉션 후에도 높게 유지되면 지속적인 압력이 있을 수 있습니다. 긴 GC 일시 중지가 노드 연결 끊김, 마스터 선거 또는 클라이언트 시간 초과와 일치하면 JVM 동작이 인시던트의 일부일 가능성이 높습니다.

Elasticsearch 노드 통계를 사용하여 JVM 동작을 확인하십시오:

curl -s "http://localhost:9200/_nodes/stats/jvm,indices,thread_pool?pretty"

힙 사용 비율, 가비지 컬렉션 횟수 및 시간, fielddata 메모리, 요청 캐시, 쿼리 캐시, 인덱싱 압력 및 거부된 스레드 풀 작업을 확인하십시오. 단일 메트릭은 오해를 불러일으킬 수 있습니다. 예를 들어, 거부된 작업이 없는 높은 힙은 검색 거부와 긴 오래된 세대 일시 중지가 있는 중간 힙보다 덜 긴급할 수 있습니다.

50% 규칙에는 이유가 있습니다.

Elasticsearch 힙을 시스템 RAM의 약 절반 이하로 유지하라는 일반적인 조언은 임의적이지 않습니다. Lucene은 디스크에서 인덱스 파일을 읽고, 운영 체제 페이지 캐시는 반복 읽기를 훨씬 빠르게 만듭니다. 거의 모든 메모리를 JVM에 할당하면 힙은 넉넉해 보일 수 있지만 OS가 핫 세그먼트를 효과적으로 캐시할 수 없기 때문에 검색 성능이 저하됩니다.

64GB 노드에서 약 30GB 또는 31GB의 힙이 일반적인 상한선입니다. 16GB 노드에서는 8GB가 시작점이 될 수 있습니다. 소규모 개발 노드에서는 Elasticsearch가 훨씬 적은 양으로 실행될 수 있습니다. 올바른 값은 워크로드, 버전 및 노드 역할에 따라 다릅니다. 전용 마스터 자격 노드는 일반적으로 핫 데이터 노드보다 훨씬 적은 힙이 필요합니다. 조정 전용 노드는 대규모 검색을 분산하고 큰 응답을 병합하는 경우 의미 있는 힙이 필요할 수 있습니다.

힙이 때때로 높다고 해서 힙을 늘리지 마십시오. 먼저 무엇이 그것을 사용하고 있는지 물어보십시오. 너무 많은 샤드, 비용이 많이 드는 집계, 큰 fielddata, 대량 벌크 요청, 거대한 검색 결과 창 및 무거운 클러스터 상태는 모두 힙을 상승시킬 수 있습니다. 힙을 늘리면 증상이 지연될 수 있지만 기본 설계는 계속 악화됩니다.

압축된 객체 포인터와 32GB 함정

많은 Java 배포판은 JVM이 압축된 일반 객체 포인터(종종 압축된 oops라고 함)를 잃을 수 있기 때문에 약 32GB 이상의 힙을 피합니다. 그렇게 되면 객체 참조가 더 많은 메모리를 차지할 수 있으며 추가 힙이 예상만큼 많은 사용 가능한 공간을 제공하지 못할 수 있습니다. 정확한 컷오프는 다를 수 있으므로 32GB를 마법의 숫자로 취급하지 말고 시작 로그를 확인하십시오.

Elasticsearch는 시작 중에 JVM 인체 공학을 기록합니다. 임계값에 가까우면 압축된 oops가 활성화되어 있는지 확인하십시오. 31g의 힙은 약간의 안전 마진을 가지고 선 아래에 머물기 위해 자주 선택됩니다. 노드에 진정으로 더 많은 메모리가 필요한 경우, 고통스러운 GC 동작이 있는 하나의 거대한 힙을 만드는 대신 노드를 추가하거나, 샤드 압력을 줄이거나, 역할을 분할하는 것이 더 나을 수 있습니다.

샤드, 매핑 및 쿼리는 JVM 문제를 만들 수 있습니다.

JVM 튜닝은 과도한 샤드 수로부터 클러스터를 구할 수 없습니다. 모든 샤드에는 데이터 구조, 세그먼트 메타데이터, 캐시, 검색 조정 및 복구 작업과 같은 오버헤드가 있습니다. 수천 개의 작은 샤드는 각 샤드에 매우 적은 데이터가 포함되어 있더라도 힙을 소비하고 클러스터 작업을 느리게 할 수 있습니다. 많은 일일 인덱스를 추가한 후 힙 문제가 나타난 경우, 해결 방법은 인덱스 수명 주기 관리 및 샤드 통합일 수 있으며 GC 플래그가 아닙니다.

매핑도 중요합니다. 텍스트 필드, 키워드 필드, 문서 값, fielddata, 중첩 문서 및 런타임 필드는 메모리 동작이 다릅니다. 큰 텍스트 필드에서 fielddata를 활성화하면 특히 비용이 많이 들 수 있습니다. 집계 중에 힙이 급증하는 경우 사용자가 해당 용도로 설계되지 않은 필드를 집계하고 있는지 확인하십시오.

쿼리는 메모리 사용 폭발을 일으킬 수 있습니다. 큰 from 값을 사용한 심층 페이지 매김, 광범위한 와일드카드 쿼리, 높은 카디널리티 집계 및 큰 결과 크기는 모두 조정 및 데이터 노드에 압력을 가합니다. search_after, 특정 시점 검색, 더 좁은 필터 및 잘 설계된 집계를 적합한 곳에 사용하십시오. 개발 중에는 무해해 보이는 쿼리가 수백 개의 샤드에서 실행될 때 심각하게 손상을 줄 수 있습니다.

벌크 인덱싱과 힙

벌크 인덱싱은 또 다른 일반적인 혼란의 원인입니다. 더 큰 벌크 요청은 특정 지점까지 처리량을 향상시킬 수 있지만, 너무 큰 요청은 메모리를 소비하고, 대기 시간을 증가시키며, 재시도를 더 비용이 많이 들게 만듭니다. 인덱싱 압력, 쓰기 스레드 풀 거부 또는 수집 중 GC 스파이크가 나타나면 JVM 플래그를 변경하기 전에 벌크 요청 크기 또는 동시성을 줄이십시오.

실용적인 접근 방식은 프로덕션과 유사한 문서로 벌크 크기를 테스트하는 것입니다. 적당히 시작하고 처리량이 개선을 멈출 때까지 증가시킨 다음 다시 줄이십시오. CPU, 힙, GC, 디스크 I/O, 병합 활동 및 거부 횟수를 모니터링하십시오. 노드가 대부분의 시간을 세그먼트 병합 또는 디스크 대기에 소비하는 경우 힙 튜닝으로 수집 병목 현상을 해결할 수 없습니다.

새로 고침 간격도 인덱싱 동작에 영향을 미칩니다. 거의 실시간 검색이 필요하지 않은 대량 수집의 경우 refresh_interval을 늘리면 세그먼트 변동을 줄일 수 있습니다. 이는 인덱스 설정이지 JVM 튜닝이 아니지만 사람들이 JVM 탓으로 돌리는 증상을 개선하는 경우가 많습니다.

컨테이너 메모리 제한

컨테이너의 Elasticsearch는 Java 버전 및 구성에 따라 JVM이 컨테이너 제한을 다르게 보기 때문에 특별한 주의가 필요합니다. 컨테이너에 4GB 메모리 제한이 있고 4GB 힙을 설정하면 오프-힙 메모리, 스레드 스택, 네이티브 메모리 및 파일 시스템 캐시에도 공간이 필요하기 때문에 프로세스가 여전히 종료될 수 있습니다.

힙을 호스트 메모리가 아닌 컨테이너 메모리 제한에 상대적으로 설정하십시오. 비힙 메모리를 위한 공간을 남겨두십시오. Kubernetes 또는 컨테이너 런타임 로그에서 OOMKilled 이벤트를 확인하십시오. 깔끔한 Elasticsearch 오류 없이 사라지는 Pod는 Java 내부에서 충돌하는 것이 아니라 플랫폼에 의해 종료되었을 수 있습니다.

Kubernetes의 경우 요청 및 제한은 실제 메모리 프로필을 반영해야 합니다. 힙에 너무 가까운 제한은 OOM 종료를 초래합니다. 너무 낮은 요청은 Pod를 다른 워크로드와 심하게 경쟁하는 노드에 배치할 수 있습니다. Elasticsearch는 기회주의적 오버커밋보다 예측 가능한 메모리 및 디스크 I/O의 이점을 누립니다.

GC 설정을 변경해야 하는 경우

대부분의 운영자는 수집기 실험을 피해야 합니다. Elasticsearch는 각 릴리스에 대해 지원되는 JVM 설정을 테스트하고 제공합니다. 이전 CMS 플래그, 공격적인 일시 중지 목표 또는 복사된 튜닝 번들을 무작위로 추가하면 시작을 방해하거나 동작을 악화시킬 수 있습니다.

로그에서 문제를 설명할 수 있는 경우에만 GC 설정을 변경하십시오: 오래된 GC 일시 중지가 너무 길거나, 젊은 GC가 너무 빈번하거나, 힙이 회복되지 않거나, 일시 중지 이벤트가 클러스터 불안정성과 일치하는 경우. 그렇더라도 작은 변경을 선호하고 롤백 경로를 유지하십시오. JVM 플래그는 프로덕션 구성의 일부이며 샤드 할당 또는 보안 변경과 동일한 검토를 거쳐야 합니다.

MaxGCPauseMillis와 같은 일시 중지 대상을 변경하는 경우 목표이지 약속이 아님을 기억하십시오. JVM은 할당 압력이 심한 경우 이를 충족하지 못할 수 있습니다. 애플리케이션이 너무 빨리 너무 많은 객체를 생성하면 수집기가 이를 무료 성능으로 전환할 수 없습니다.

간단한 인시던트 체크리스트

Elasticsearch 지연 시간이 스파이크되고 JVM이 의심되는 경우 다음 순서로 확인합니다:

하나 또는 두 개의 노드가 비정상인가요, 아니면 전체 클러스터가 영향을 받았나요?
힙 사용량이 지연 시간과 동시에 증가했나요?
오래된 세대 GC 일시 중지가 발생했으며, 얼마나 길었나요?
검색 또는 쓰기 스레드 풀이 작업을 거부하고 있나요?
인덱싱 속도, 벌크 크기 또는 쿼리 볼륨이 변경되었나요?
최근에 샤드 수, 세그먼트 수 또는 클러스터 상태 크기가 증가했나요?
디스크 I/O 지연 시간이 높은가요?
배포, 매핑 변경 또는 새 대시보드 쿼리가 같은 시기에 시작되었나요?

이 체크리스트는 조사를 현실에 기반하게 유지합니다. JVM 튜닝은 레버이지만 여러 레버 중 하나일 뿐입니다.

실용적인 핵심 요점

적절한 JVM 설정은 Elasticsearch가 안정적으로 유지되도록 돕지만, 대부분의 이점은 힙을 신중하게 크기 조정하고, 파일 시스템 캐시를 위한 공간을 남겨두고, 실제 GC 동작을 관찰하고, 메모리 압력을 생성하는 샤드 또는 쿼리 문제를 해결하는 데서 옵니다. -Xms와 -Xmx를 동일하게 유지하고, 압축된 oops 임계값 근처에서 보수적으로 유지하며, 증거가 반대를 말할 때까지 버전 기본값을 신뢰하고, GC 로그를 장식이 아닌 운영 증거로 취급하십시오.