Elasticsearch 힙 크기 사용량 및 JVM 가비지 수집
모범 사례와 힙 메모리 사용량이 너무 많거나 JVM 성능이 최적이 아닐 때 문제를 해결하는 방법을 포함해 Elasticsearch 힙 크기 사용량과 JVM 가비지 수집에 대해 살펴봅니다.
New to Elasticsearch? Join our getting started with Elasticsearch webinar. You can also start a free cloud trial or try Elastic on your machine now.
힙 크기는 Elasticsearch 노드의 Java 가상 머신에 할당된 RAM의 양입니다.
버전 7.11부터 Elasticsearch는 기본적으로 노드의 역할과 총 메모리를 기반으로 JVM 힙 크기를 자동으로 설정합니다. 대부분의 프로덕션 환경에서는 기본 사이징을 사용하는 것이 좋습니다. 그러나 JVM 힙 크기를 수동으로 설정하려면 일반적으로 -Xms 및 -Xmx를 동일한 값으로 설정해야 하며, 최대 (대략) 31GB를 기준으로 총 사용 가능한 RAM의 50% 이 되어야 합니다.
힙 크기가 클수록 노드에 인덱싱 및 검색 작업을 위한 더 많은 메모리를 확보할 수 있습니다. 그러나 노드에는 캐싱을 위한 메모리도 필요하므로 50% 을 사용하면 둘 사이의 균형이 잘 유지됩니다. 프로덕션 환경에서도 이와 같은 이유로 Elasticsearch와 동일한 노드에서 다른 메모리 집약적인 프로세스를 사용하지 않아야 합니다.
일반적으로 힙 사용량은 톱니 모양 패턴을 따르며, 사용 중인 최대 힙의 약 30~70%(% ) 사이에서 진동합니다. 이는 가비지 수집 프로세스가 메모리를 다시 확보할 때까지 JVM이 힙 사용률을 꾸준히 증가시키기 때문입니다. 높은 힙 사용량은 가비지 수집 프로세스가 따라잡지 못할 때 발생합니다. 힙 사용량이 많다는 지표는 가비지 컬렉션이 힙 사용량을 약 30개% 로 줄일 수 없는 경우입니다.
위 이미지에서 JVM 힙의 일반적인 톱니 모양을 볼 수 있습니다.
또한 가비지 컬렉션에는 젊은 가비지 컬렉션과 오래된 가비지 컬렉션의 두 가지 유형이 있음을 알 수 있습니다.
정상적인 JVM에서 가비지 컬렉션은 다음 조건을 이상적으로 충족해야 합니다:
젊은 GC는 빠르게 처리됩니다(50ms 이내).
젊은 GC는 자주 실행되지 않습니다(약 10초).
이전 GC는 빠르게 처리됩니다(1초 이내).
이전 GC는 자주 실행되지 않습니다(10분에 한 번 이상).
힙 메모리 사용량이 너무 많거나 JVM 성능이 최적이 아닌 경우 해결하는 방법
힙 메모리 사용량이 증가하는 데에는 여러 가지 이유가 있을 수 있습니다:
오버하딩
오버하딩에 대한 문서는 여기를 참조하세요.
대규모 집계 크기
집계 크기가 커지는 것을 방지하려면 쿼리의 집계 버킷 수(크기)를 최소한으로 유지하세요.
GET /_search
{
"aggs" : {
"products" : {
"terms" : {
"field" : "product",
"size" : 5
}
}
}
}느린 쿼리 로깅(느린 로그)을 사용하고 다음을 사용하여 특정 인덱스에 구현할 수 있습니다.
PUT /my_index/_settings
{
"index.search.slowlog.threshold.query.warn": "10s",
"index.search.slowlog.threshold.query.info": "5s",
"index.search.slowlog.threshold.query.debug": "2s",
"index.search.slowlog.threshold.query.trace": "500ms",
"index.search.slowlog.threshold.fetch.warn": "1s",
"index.search.slowlog.threshold.fetch.info": "800ms",
"index.search.slowlog.threshold.fetch.debug": "500ms",
"index.search.slowlog.threshold.fetch.trace": "200ms",
"index.search.slowlog.level": "info"
}결과를 반환하는 데 시간이 오래 걸리는 쿼리는 리소스 집약적인 쿼리일 가능성이 높습니다.
과도한 벌크 인덱스 크기
대량의 요청을 전송하는 경우 힙 사용량이 많은 원인이 될 수 있습니다. 대량 인덱스 요청의 크기를 줄이세요.
매핑 문제
특히 "fielddata: true"를 사용하는 경우, 이는 JVM 힙의 주요 사용자가 될 수 있습니다.
힙 크기가 잘못 설정됨
힙 크기는 수동으로 정의할 수 있습니다:
환경 변수 설정하기:
ES_JAVA_OPTS="-Xms2g -Xmx2g"Elasticsearch 구성 디렉터리에서 jvm.options 파일을 편집합니다:
-Xms2g
-Xmx2g환경 변수 설정은 파일 설정보다 우선합니다.
설정을 적용하려면 노드를 다시 시작해야 합니다.
JVM 새 비율이 잘못 설정됨
Elasticsearch는 기본적으로 이 값을 설정하므로 일반적으로 이 값을 설정할 필요가 없습니다. 이 매개변수는 JVM에서 "신세대" 및 "구세대" 오브젝트에 사용할 수 있는 공간의 비율을 정의합니다.
오래된 GC가 매우 자주 발생하는 경우, Elasticsearch 구성 디렉터리의 jvm.options 파일에서 이 값을 구체적으로 설정해 볼 수 있습니다.
-XX:NewRatio=3대규모 Elasticsearch 클러스터에서 힙 크기 사용량과 JVM 가비지 수집을 관리하기 위한 모범 사례는 무엇인가요?
대규모 Elasticsearch 클러스터에서 힙 크기 사용량과 JVM 가비지 수집을 관리하기 위한 모범 사례는 힙 크기를 사용 가능한 RAM의 최대 50% 로 설정하고 JVM 가비지 수집 설정이 특정 사용 사례에 최적화되도록 하는 것입니다. 클러스터가 최적으로 실행되고 있는지 확인하기 위해 힙 크기와 가비지 수집 메트릭을 모니터링하는 것이 중요합니다. 특히 JVM 힙 크기, 가비지 수집 시간, 가비지 수집 일시 중지를 모니터링하는 것이 중요합니다. 또한 쓰레기 수거 횟수와 쓰레기 수거에 소요되는 시간을 모니터링하는 것도 중요합니다. 이러한 메트릭을 모니터링하면 힙 크기나 가비지 수집 설정에 잠재적인 문제가 있는지 파악하고 필요한 경우 수정 조치를 취할 수 있습니다.
