Elasticsearch CircuitBreaker GC 관련

---

최근 사내에서 검색엔진인 엘라스틱서치 클러스터 중 하나의 노드가 다운되고 샤드가 옮겨지는 과정에서 검색 API 지연이 발생하였습니다.

노드는 바로 올라와 크게 지연은 있지 않았지만 비정상 종료이기 때문에 해당 서버와 노드의 지표를 찾아보았고 Heap Memory가 가득 차면서 CircuitBreaker가 발생하고 종료된 걸 확인할 수 있었습니다.

 

노드가 다운되는 시점과 GC Old 영역의 쌓여있던 객체를 정리하는 시점과 동일했기 때문에 해당 과정이 원인이라 생각하게 되었고 GC가 발생하게 된 대용량 색인이나 검색 요청이 있었는지 확인해 보았지만 크게 이상은 없어 정확한 원인을 찾지 못했습니다...

 

 

---

 

 

2023.10.26 - [ELK] - Elasticsearch Essential 트러블 슈팅 사례

Elasticsearch Essential 트러블 슈팅 사례

GC 관련된 문제인 거 같아 튜닝 방법을 찾다가 위 글에 5번 사례와 일치한다고 생각했지만 현재 사용하는 검색엔진의 7.8대의 버전에서는 CMS GC가 아닌 G1 GC를 사용하기 때문에 NewRatio와 SurvivorRatio를 사용하지는 못했습니다.

 

 

---

 

 

https://opster.com/guides/elasticsearch/capacity-planning/elasticsearch-heap-size-usage/

Elasticsearch Heap Size & JVM Garbage Collection

https://discuss.elastic.co/t/is-this-normal-seeing-jvm-heap-zigzag-chart/139215

Is this normal seeing JVM Heap Zigzag chart

 

두 개의 링크를 읽어 보고 현재 운영 중인 검색 엔진의 JVM Heap Memory 그래프가 정상적이지 않아 보였습니다.

실시간 색인이 필요하여 수많은 벌크 색인 요청과 검색 API 호출량 때문에 정상적인 톱니바퀴 형식의 그래프가 아니라 Heap Memory가 가득 찬 채로 불규칙적으로 처리되고 있었습니다.

 

정상적인 JVM에서는 가비지 수집이 다음 조건을 이상적으로 충족해야 함.

• Young GC는 빠르게 처리됩니다(50ms 이내).
• Young GC는 자주 실행되지 않습니다(약 10초).
• Old GC는 빠르게 처리됩니다(1초 이내).
• Old GC는 자주 실행되지 않습니다(10분에 한 번 이상).

 

위 링크에 문제 원인이 될만한 요소로는 아래와 같이 있다고 적혀있어서 아래 내용을 더 살펴봐야 할 듯싶습니다.

• 오버 샤딩
• 대규모 집계 크기
• 과도한 벌크 인덱스 크기
• 매핑 문제
• 힙 크기가 잘못 설정됨