우리의 ES는 아직 느리지 만 최적화하지는 않았지만 this link에 따르면 탄성으로부터의 요청 거부는 속도를 늦추고 적응 시키라는 피드백의 한 형태입니다. 벌크의 크기.탄성이 응력 하에서 일치하지 않는 결과를 나타냅니다.
차단 대량 (동시에 전송 된 개별 요청 목록, 아직 Google 검색을 사용하지 않는 목록)의 크기가 이전 대량에서 거부 된 요청 수에 따라 역 압박 양식을 만들었습니다. 현재 대량이 완료 될 때까지 기다렸다가 새 것을 시작합니다. 분명히 모든 거부 된 요청은 요청 큐에 다시 입력됩니다 (쿼리를 작성하는 데 필요한 데이터 형태로). 예를 들어, Elastic이 500 개의 동시 요청을 처리 할 수 있고 600을 전송하면 일부는 거부되고 새로운 크기는 480 (20 % 할인)으로 줄어 듭니다.
우리가 발견 한 것은 ES가 이전에 거부 된 요청에 대해 다른 결과를 반환한다는 것입니다. 예를 들어 예상 결과와 같은 값을 반환하지만 오프셋 값은 2입니다. 주소에 1 개의 결과가 있어야하지만이 버그로 인해 주소가없는 결과도 누락됩니다.
대량 크기가 ES에서 처리 할 수있는 임계 값보다 작 으면 모든 것이 예상대로 진행되고 예상되는 결과를 얻습니다.
라이브러리의 (elastic4s) 문제인 것처럼 보이지 않습니다.
탄성 구성 : 2 CPU 32 기가 바이트의 RAM 16 기가 바이트 힙 : 5 개 파편 각 노드 당
와 2 노드. 그 외 모든 것은 기본값입니다
인터넷에서 정보를 찾을 수 없습니까?이 문제가 있습니까? 해결책은 무엇입니까? 우리가 지금까지 시도 무엇
: 벌크 사이
Thread.sleep링크 위에서 알 수 있듯이.쿼리 수준에서 캐시 제거 및 인덱스에서 제거.
다른 (느린) 하드웨어에서 동일한 색인을 시도합니다.
문제가 (우리 코드에서) 경쟁 조건이 아닌 것으로 확인되었습니다.
업데이트 :
the query이 좋아하는 무엇. 검색
스레드 풀 : "search" : { "type" : "fixed", "min" : 4, "max" : 4, "queue_size" : 1000 },
2 UPDATE :
우리는 또한 (가 파편에 문제라고 생각하는) 우리의 질의에 환경 설정을 시도 : .preference(Preference.Primary) 어떤 긍정적 인 결과 (심지어 그들이 있었다 전에보다 무작위로). 이 설정으로 두 번 연속 실행하면 "임의"결과가 달라 지므로 일관성이 없습니다.