해결된 질문
작성
·
550
·
수정됨
0
안녕하세요 선생님, elasticsearch 운영에 관해 질문이 있어 드립니다.
제가 노드를 구성하고 힙사이즈를 32g로 주었습니다.
"OPENSEARCH_JAVA_OPTS=-Xms32g -Xmx32g"
처음에는 괜찮았는데 한달정도 지나니 꽉차서 쿼리가 안되더라구요
jvm.options는 바꾼거 없이 이렇게 다 잘들어갔습니다.
## GC configuration
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
가비지 컬렉션을 사용하고, 힙메모리의 75% 가 사용되면 old GC 를 진행해야되는데 진행이 안되는것같아서요.
어떻게 힙메모리를 줄일수있을까요..
감사합니다..
답변 2
1
선생님 원인을 찾았습니다. 과도한 샤드 할당이 문제 였네요
Size your shards | Elasticsearch Guide [7.17] | Elastic
인덱스 정책을 변경하면서 하루에 샤드만 거의 50개를 생성해서 한 노드당 300개 이상의 샤드가 할당되었습니다.
공식문서에서는 600개라고 했지만 제 환경에서는 300개가 넘으면 힙사이즈가 꽉차는 현상이 발생했네요
우선 레플리카 다 삭제하고 몇개 인덱스를 삭제해서 복구했습니다
감사합니다^^
0
JVM 힙 메모리 사용량 그래프를 볼 수 있을까요? Old GC는 반드시 발생하기 때문에 아마도 다른 문제가 있을 것 같습니다. 예를 들어 문제가 생기는 시점에 무거운 쿼리가 동작해서 Old GC 가 동작하기도 전에 메모리에 문제가 생길 수도 있습니다.
검색/색인 요청량 및 지연시간에 대한 그래프, CPU 사용률 그래프, JVM 힙 메모리 사용량 그래프를 함께 보면서 분석해 보면 좋을 것 같습니다.
선생님 책 보면 223페이지에 fieldata인 필드 데이터 캐시크기가 노드의 힙 메모리 공간을 많이 차지한다고 적혀있어
POST /index_name/_cache/clear?fielddata=true
을 통해 주요 인덱스의 캐시를 모두 삭제했습니다.
memory_size_in_bytes 값이 49825820680 -> 123492 까지 낮아지고
힙 메모리를 보니 절반으로 줄었습니다. 감사합니다^^
근데 항상 이 값을 수동으로 줄이는건 아닌것같은데 필드 데이터 캐시 관련하여 설정값이 따로 있나요?
fielddata
는 text
타입의 데이터들을 기반으로 통계 작업 같은 것을 할 때 사용 되는 데이터 입니다. 기본으로는 비활성화 되어 있어서 일반적으로는 fielddata
때문에 문제를 겪게 되는 일이 흔치는 않습니다. 아마 사용하시는 text
타입의 데이터들 중 fielddata
가 활성화 되어 있는 매핑이 존재할 것 같은 데 확인 해보시고 불필요 하다면 비활성화 하시면 됩니다.
아마도 아래와 같이 활성화 되어 있을 겁니다. 아래는 name
이라는 이름의 text
타입 데이터에 fielddata
가 활성화 되어 있는 매핑 정보 입니다.
{
"properties": {
"name": {
"type": "text",
"fielddata": true
}
}
}
키바나 같은 시각화 도구를 통해서 통계 작업 같은 것을 하려면 keyword
타입으로 사용하거나 keyword
타입을 서브로 설정해서 사용하는 게 좋습니다.
{
"properties": {
"name": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword"
}
}
}
}
}
위와 같이 매핑 정보를 만들면 (동적 매핑으로도 생성되는 구조 입니다.) 키바나 같은 도구를 이용할 때 name.keyword
데이터를 이용해서 통계 작업이나 시각화를 하면 됩니다.
참고로 fielddata
를 자동으로 삭제하는 기능은 없어서 만약 fielddata
를 계속 사용하려 한다면 주기적으로 삭제해 줘야 합니다.
캐시 삭제후 그 즉시만 힙이 줄어들고 다시 곧바로 풀로 차더라구요... 다음날 GC did bring memory usage down 오류로 모든 노드가 내려갔습니다.. 제가 책에 12장 클러스터 구축 시나리오에 1번 일 100GB 데이터 분석용 클러스터를 참고해서 클러스터를 구성했습니다. 제 생각에는 클러스터 환경이 부족하다고 생각하지는 않는데 계속 메모리부족이 뜨니깐 혹시 계속 이런 상황이 발생하면 데이터 노드를 더 늘리거나 해야될까요??
하루에 프라이머리 샤드만 70~80GB /레플리카 합쳐서 140 GB~160GB
마스터 3개 (1개는 전용, 2개는 데이터노드 겸용)
데이터 4개
코디네이터 1개
-> 총 8개 노드, 데이터 노드 6개(마스터 겸용2개)
각 노드에 볼륨 7테라
인덱스 프라이머리 샤드 3개 레플리카 1개
인덱스 100일 지나면 delete
힙 모든 노드 31기가
아래는 6시간동안 받는 매트릭입니다. 갑자기 힙 차면서 down 되더라구요 저 때는 인덱스 unssinged 된거 삭제하는 작업을 하고 있었는데 말이죠 즉 쿼리수가 굉장히 적었습니다 cat /_nodes와 같은 간한단 api 20개 정도 생성했습니다.
필드 데이터를 사용하도록 되어 있는 text
필드들을 전부 비활성화 해야 현상이 나아질 것 같습니다. 그렇지 않으면 의도치 않게 작은 쿼리들로도 계속 힙 메모리에 필드 데이터들이 차오를 가능성이 있거든요.
매핑 정보를 바꿔야 하니까 매핑 정보를 새로 만들어서 새 인덱스에 재색인을 하는 방식으로 작업할 수 있습니다.
로그 수집 용도라면 일단 오늘 로그까지는 기존 매핑 정보로 수집하고 내일 로그 부터는 필드 데이터를 사용하지 않도록 설정된 매핑 정보로 인덱스를 만들어서 수집하면 됩니다.
선생님 혹시 인덱스 갯수도 힙사이즈에 영향을 미치나요..?
제가 그 전에는 한개의 인덱스 템플릿으로 데이터를 받았는데(프라이머리 3개, 레플리카 1개- 하루에 총 6개 인덱스 샤드 생성)
일주일 전부터 5개 인덱스 템플릿을 나눠서 받고 있거든요(프라이머리 3개, 레플리카 1개- 하루에 총 30개 인덱스 샤드 생성)
그래서 그 전에는 32기가로 늘리고 이런 문제가 없었는데 늘린 이후에 힙사이즈가 계속 꽉차서 내려오지 않는 상황이 발생하고 있는거라
혹시 샤드갯수때문이 아닌가 생각이 들어서요
그렇군요. 보통 저 같은 경우에는 노드 당 샤드의 개수가 많았던 적은 없었어서 같은 이슈를 겪지 않았던 것 같네요. 방법을 찾으셨다니 다행 입니다. 저도 시간이 나면 샤드와 힙 메모리 간의 관계에 대해 좀 더 분석해 보고 찾아 보겠습니다.