JVM GC 모니터 서비스 오버헤드: 근본 원인과 권장사항

문제 설명

The JvmGcMonitorService 오버헤드경고는 Java 가상 머신(JVM)이 Old Generation Garbage Collection(GC)을 수행하고 있음을 나타냅니다. 이 과정 동안 JVM은 메모리를 회수하기 위해 다른 모든 작업을 일시 중지하며, 다음과 같은 잠재적인 중단을 초래할 수 있습니다:

• 응답 없음Elasticsearch 노드가 클라이언트 또는 클러스터 요청에 응답하지 않음.
• 노드 연결 끊김, 이는 클러스터의 불안정을 초래할 수 있습니다.

1. 과도한 힙 사용: 많은 수의 복잡한 쿼리 또는 설정된 JVM 힙 크기와 관련하여 너무 많은 샤드가 할당됨.
2. 리소스 구성 불량: JVM 설정 또는 샤드 분배가 잘못 조정됨.

첫 발견 및 관찰

1. 힙 사용 추세:

• 모니터링 도구(예: Kibana의 스택 모니터링 또는_nodes/statsAPI의 메트릭)를 사용하여 시간에 따른 JVM 힙 사용을 검사합니다.
• 힙 포화 또는 장기간의 GC 일시 중지를 발견합니다.

1. 사용할 명령어:
2. GET /_nodes/stats/jvm
3. 샤드 할당 및 크기:

• 각 노드의 샤드 수 및 크기를_cat/shards를 사용하여 검토합니다. 과도한 샤드 수는 메모리 소비를 증가시킵니다.

1. 사용할 명령어:
2. GET /_cat/shards?v
3. 쿼리 복잡성:

• 느린 쿼리 로그를 분석하거나 자주 실행되는 쿼리를 모니터링합니다. 복잡한 집계나 와일드카드 검색은 JVM 메모리를 많이 소모합니다.

1. 느린 로그 활성화 명령어:
2. # elasticsearch.yml에 추가
3. index.search.slowlog.threshold.query.warn: 10s
4. index.search.slowlog.threshold.fetch.warn: 5s
5. 비정상적인 패턴:

• GC 오버헤드 발생 시 인덱싱, 검색 속도 급등 및 기타 이상 활동을 확인합니다.

권장 사항

JVM 힙 설정 최적화:

• 힙 크기를 적절하게 설정합니다(사용 가능한 메모리의 50%, 압축된 객체 포인터가 비활성화되지 않도록 최대 30GB로 제한).
• G1GC를 활성화하여 대형 힙과 높은 처리량 시나리오에 대한 성능을 개선합니다.

샤드 수 줄이기:

• 작은 인덱스를 결합하거나Rollover API 를 사용하여 인덱스 성장을 관리합니다.
• 일반적인 지침으로 힙 메모리 1GB당 20개의 샤드를 목표로 합니다.

쿼리 튜닝:

• 비싼 쿼리를 재작성하여 효율성을 개선합니다(예:*또는 와일드카드에? 를 피함).
• 자주 사용되는 쿼리를 검색 쿼리 캐시를 사용하여 캐싱합니다.

모니터링 및 알림 구현:

• Elastic의 모니터링 도구를 사용하여 높은 힙 사용량 또는 느린 GC 시간에 대한 알림을 생성합니다.

클러스터 확장:

• 워크로드 요구가 지속적으로 용량을 초과하는 경우, 클러스터에 노드를 추가하여 부하를 분산시키는 것을 고려합니다.

결론