2024-09-09T12:28:46.231Z

0

답변 감사합니다. VisualGC를 통한 힙메모리 분석은 Linux에서는 힘들것 같고, MacOS 또는 Windows에 Elasticsearch를 직접 띄워서 해야겠군요..

1의 경우 현재 문서를 10MB만 색인하고 있고, 3의 경우 heap size를 31GB -> 64GB로 늘렸을 때 목숨이 연장될 뿐 CircuitBreaker 발동은 피할 수 없었습니다. 말씀주신 2로 테스트하여 standard vs Edgengram(gram:1~10)을 비교해보는게 지금으로서는 가장 좋은 테스트 같습니다 ㅎㅎ

제가 아직 Heap Dump를 떠본적은 없지만, [Lucene in Action]을 살펴보면 아래와 같이 색인하게 되는데 아무래도 Field 객체나 Document 객체보다는 String 타입의 객체가 무수히 많이 생기는 것을 의심하고 있습니다.

final Settings settings = newAnalysisSettingsBuilder()
        .put("min_gram", 2)
        .put("max_gram", 3)
        .putList("token_chars", "letter", "custom")
        .put("custom_token_chars", "_-")
        .build();
Tokenizer tokenizer = new EdgeNGramTokenizerFactory(
        IndexSettingsModule.newIndexSettings(index, indexSettings),
        null,
        name,
        settings
).create(); 
tokenizer.setReader(new StringReader("Abc -gh _jk =lm"));
assertTokenStreamContents(tokenizer, new String[] { "Ab", "Abc", "-g", "-gh", "_j", "_jk", "lm" });

이번 기회에 왜 ES(Java) 프로세스 내에서 Mixed/Full GC가 발생함에도 객체 참조가 해제되지 않아 Heap을 꽉 채우는지(객체의 Reachability 관점에서) 확실히 조사해보고 싶은데 쉽지 않네요..

0

도움이 될지 모르겠지만, 비슷한 질문이 있었는데 https://www.inflearn.com/community/questions/1204799/compressed-oop-%EC%A1%B0%EA%B1%B4%EC%97%90-%EB%94%B0%EB%A5%B8-es-heap-size-%EC%A0%9C%EC%95%BD 이 내용을 한 번 참고 하시면 좋을 것 같습니다.

저도 ElasticSearch 클러스터를 운영한지는 꽤 되어서 지금 당장 도움이 될 만한 방안들을 고민해 보기가 쉽지 않네요. (__)