2014-01-08 1 views
6

Solr 설정이 있습니다. 복제를 위해 하나의 마스터와 두 개의 슬레이브. 우리는 약 70 만 개의 문서를 색인에 포함하고 있습니다. 슬레이브에는 16GB의 RAM이 있습니다. OS 및 HD 용 10GB, Solr 용 6GB.Solr 필터 캐시 (FastLRUCache)가 너무 많은 메모리를 사용하고 메모리를 초과합니까?

하지만 때때로, 노예는 기억이 없습니다. 메모리가 부족하기 바로 전에 덤프 파일을 다운로드하면 클래스 :

org.apache.solr.util.ConcurrentLRUCache$Stats @ 0x6eac8fb88 

이 최대 5Gb의 메모리를 사용하고 있음을 알 수있었습니다. 우리는 필터 캐시를 광범위하게 사용하고 있으며, 93 %의 적중률을 가지고 있습니다. 그리고 여기에 쿼리 결과이 같은 설정이 solrconfig.xml

<property name="filterCache.size" value="2000" /> 
<property name="filterCache.initialSize" value="1000" /> 
<property name="filterCache.autowarmCount" value="20" /> 

<filterCache class="solr.FastLRUCache" 
      size="${filterCache.size}" 
      initialSize="${filterCache.initialSize}" 
      autowarmCount="${filterCache.autowarmCount}"/> 

의 필터 캐시에 대한 XML, 그러나 LRUCache를 사용하고 그것은 단지 메모리 약 35MB 사용합니다. 수정해야 할 구성에 문제가 있습니까? 아니면 필터 캐시에 더 많은 메모리가 필요합니까?

답변

12

친구가 필터 캐시가 얼마나 대략적으로 작동 하는지를 알게 된 후 가끔씩 메모리 오류가 발생하는 이유가 분명해졌습니다.

그럼 필터 캐시는 무엇을합니까? 기본적으로 어떤 문서가 필터와 일치하는지 알려주는 비트 배열과 같은 것을 만듭니다. 예를 들면 다음과 같습니다.

cache = [1, 0, 0, 1, .. 0] 

1은 0을 의미하고 0은 적중을 의미합니다. 예를 들어 필터 캐시가 0 번째 및 3 번째 문서와 일치 함을 의미합니다. 따라서 캐시는 전체 문서의 길이와 비슷합니다. 그래서 제가 50 백만 개의 워드 프로세서를 가지고 있다고 가정 해 봅시다. 배열 길이는 50 백만입니다. 즉, 하나의 필터 캐시가 램에서 50,000,000 비트를 차지할 것입니다.

그래서 우리는 우리가 2000 필터 캐시를 원하는 지정, 그 의미가 소요됩니다 RAM은 대략 다음과 같습니다

50.000.000 * 2000 = 100.000.000.000 bit 

당신이 기가로 변환합니다.그러면 다음과 같이됩니다 :

따라서 필터 캐시에 필요한 RAM의 총량은 대략 12Gb입니다. Solr에 6Gb 힙 공간 만 있으면 2000 필터 캐시를 만들 수 없다는 뜻입니다.

예, Solr이 항상이 배열을 생성하지 않는다는 것을 알고 있습니다. 필터 쿼리의 결과가 낮 으면 메모리를 적게 차지하는 다른 것을 만들 수 있습니다. 이 계산은 숫양에 2000 개의 캐시가있는 경우 대략적으로 필터 캐시의 상한선이 얼마나되는지를 나타냅니다. 다른 경우에는 더 낮을 수 있습니다.

그래서 한 가지 해결책은 solr config의 최대 필터 캐시 수를 줄이는 것입니다. 우리는 solr 통계를 검사했습니다. 대부분 600 개의 필터 캐시 만 있으므로 대부분 필터 캐시 수를 줄일 수 있습니다.

또 다른 옵션은 물론 더 많은 RAM을 추가하는 것입니다.

+0

캐시 크기를 절반으로 줄이면 안정적입니다. 필자는 필터 캐시에 대한 설명 때문에 대답으로 선택했습니다. 그러나 Persimmonium의 대답은 실제로 사람이 할 수있는 측면에서 더 낫습니다. – Rowanto

8

일부 옵션 :

  1. 캐시의 크기를 감소, 당신은 여전히 ​​좋은 적중률
  2. 교체 solr.LFUCache와 LRU을 (Frequenty가 사용하는 최소)이있는 경우, 아마와 연동 해에서 볼 점 하나는 여전히 쿼리 할 때 경우, 때로는의 FQ는 매우 드문 것 알고

    FQ = {! 캐시 = 거짓} inSto을 사용함으로써, 캐시 그나마 좋은 적중률

  3. 을 줄 것이다 CK :

  4. 물론 사실은, 더 많은 메모리를 얻을 또 다른 옵션

  5. (..., facetting 정렬) DocValues가 여기에 도움이 경우 그들은 다른 시나리오 메모리에 도움 않는, 조사,하지만 확실하지 않다 fq

  6. 최신 릴리스가 아닌 경우 업그레이드하십시오.

관련 문제