범위 검색 쿼리로 인해 탄성 검색에서 가비지 수집이 발생했습니다.

Question

16 노드 (13 데이터 노드/3 마스터/24GB RAM/12GB 힙)의 Elastic Search 5.2 클러스터가 있습니다. 성능을 테스트하고 Elastic 클러스터에서 초당 50 회의 검색 쿼리를 수행합니다. 내 쿼리는 다음과 같습니다 -

{ 
    "query": { 
     "bool": { 
      "must": [ 
       { 
        "term": { 
         "cust_id": "AC-90-464690064500" 
        } 
       }, 
       { 
        "range": { 
         "yy_mo_no": { 
          "gt": 201701, 
          "lte": 201710 
         } 
        } 
       } 
      ] 
     } 
    } 
} 

내 인덱스 매핑은 다음과 같다 -

가

cust_id  Keyword 
smry_amt  Long 
yy_mo_no  Integer // doc_values enabled 
mkt_id  Keyword 
. . . 
. . . 
currency_cd Keyword // Total 10 field with 8 Keyword type 

인덱스는 2 억 개 레코드를 포함하고 각 CUST_ID에 대한 기록의 100 단위가있을 수 있습니다. 색인에는 2 개의 복제본이 있습니다. 레코드 크기는 100 바이트 미만입니다.

성능 테스트를 10 분 동안 실행하면 쿼리 응답과 성능이 매우 느리게 나타납니다. 키바 모니터링 탭에서 세부 사항을 좀 더 조사하면, 그것은 일어나는 쓰레기 수거 활동을 많이 있다는 것을 나타납니다. (PLS 아래 이미지 참조) -

내가 내 마음에 몇 가지 질문 혼탁 있습니다. Range 쿼리에 대한 연구를 수행했지만 광산과 유사한 시나리오에서 GC 활동을 유발할 수있는 것에 대해서는별로 알지 못했습니다. 메모리 사용량과 GC 활동에 대해서도 연구하지만, 대부분의 Elastic 문서에서는 색인 생성 중에 젊은 세대 GC가 정상이며 검색 활동은 주로 OS가 유지 관리하는 파일 시스템 캐시를 사용합니다. 그 이유는 위의 차트에서 검색이 파일 시스템 캐시를 사용하고 있기 때문에 Heap이 많이 사용되지 않았기 때문입니다.

지금 - 여기에서 발생하는 가비지 컬렉션의 원인이 될 수있는 어떤

1. ?
2. 힙은 여전히 ​​Elastic Search에서 사용 가능하며 사용 된 힙은 사용 가능한 것과 비교할 때 여전히 매우 적음을 보여줍니다. 그러면 GC를 트리거하는 것은 무엇입니까?
3. 쿼리 유형 때문에 내부 데이터 구조가 생성되어 처리가 중단되어 GC가 발생합니까?
4. CPU 스파이크가 GC 일 수 있습니다.
5. Elastic Search 5.5 이전 버전에서 Range 쿼리를 실행하는 다른 효율적인 방법이 있습니까?
6. 쿼리를 프로파일 링하면 TermQuery 및 BooleanQuery이 실행 중이며 가장 나중에 사용되는 것으로 나타납니다.

어떤 아이디어가 여기에 있습니까? 사전에

감사합니다,

• SGSI.

Answer 1

정답은 색인 설정에 따라 다르지만 사용 가능한 docValues가있는 정수 유형을 사용하고있는 것 같습니다. 이 데이터 구조는 집계 및 정렬을 지원하지만 범위 쿼리는 지원하지 않습니다. 올바른 데이터 유형은 range입니다.

DocValues의 경우 elastic/lucene은 모든 문서 (예 :범위 쿼리와 일치시키기 위해 DV 열에서 모든 값을 읽고 디코딩해야합니다. 특히 운영 체제에서 인덱스를 캐시 할 수없는 경우이 작업은 비용이 많이 듭니다.