Solr Filter Cache（FastLRUCache）が多すぎるメモリを消費し、メモリが不足していますか？

Question

私はSolrの設定をしています。レプリケーションのための1つのマスターと2つのスレーブ。私たちは約70百万の文書をインデックスに収めています。スレーブには16 GBのRAMがあります。 OSとHDでは10GB、Solrでは6GB。

しかし、時々、スレーブのメモリが不足しています。

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

メモリの最大5 GBまで使用されています。我々はそれがメモリ不足だった直前にダンプファイルをダウンロードしたとき、私たちは、クラスがいることを見ることができました私たちはフィルターキャッシュを広範囲に使用していますが、ヒット率は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を使用しているとそれだけでメモリの35メガバイト程度使用しています。固定する必要のある設定に何か問題がありますか？それとも、フィルタキャッシュにもっと多くのメモリが必要ですか？

Answer 1

友人がフィルタキャッシュの処理方法を大まかに教えてくれた後、私たちは時々メモリエラーから逃れる理由が明らかになりました。

フィルタキャッシュは何をしますか？ 基本的には、どのドキュメントがフィルタにマッチするかを示すビット配列のようなものを作成します。次のようなものがあります。

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

1はヒットしないことを意味し、0はヒットしないことを意味します。したがって、この例では、フィルタキャッシュが0番目と3番目のドキュメントに一致することを意味します。したがって、キャッシュは、ドキュメント全体の長さで、ビットの配列のようなものです。ですから、5000万のドキュメントがあるとしましょう。配列の長さは50000000です。これは、1つのフィルタキャッシュがラムの50,000ビットを占めることを意味します。

だから我々は、我々は2000フィルタキャッシュを望ん指定、それがかかりますRAMはおおよそであることを意味：

50.000.000 * 2000 = 100.000.000.000 bit 

あなたはGBにそれを変換する場合。

100.000.000.000 bit/8 (to byte)/1000 (to kb)/1000 (to mb)/1000 (to gb) = 12,5 Gb 

したがって、フィルタキャッシュだけで必要な合計RAMは約12Gbです。つまり、Solrに6Gbのヒープスペースしかない場合、2000個のフィルタキャッシュを作成することはできません。

はい、Solrは常にこの配列を作成するとは限りません。フィルタクエリの結果が低い場合は、メモリを消費するものを作成することができます。この計算では、ラムに2000個のキャッシュがある場合、フィルタキャッシュの上限がどれくらいあるかがわかります。他のより良いケースではそれは低くなる可能性があります。

解決策の1つは、solr configの最大フィルタキャッシュの数を減らすことです。私たちはsolrの統計値をチェックしました。ほとんどの場合、約600のフィルタキャッシュしかないので、フィルタキャッシュの数を最大に減らすことができます。

もう1つのオプションはもちろんRAMを追加することです。

Answer 2

いくつかのオプション：

1. キャッシュのサイズを小さくし、あなたはまだ良いヒット率を持っているかどうかを確認
2. 多分と接続詞で、solr.LFUCacheとLRUの（最小Frequentyが使用される）を交換照会時に、時にはあなたはFQは

   FQ = {！キャッシュ=偽} inStoを使用することによって、それをキャッシュいけない、非常にまれなことがわかっている場合はポイント1はまだ良いヒット率

3. を与えるだろうCK：

4. もちろんの真のは、より多くのメモリを取得することは、別のオプション

5. （...、面取りソート）DocValuesがここに役立つならば、彼らは他のシナリオでのメモリを助けるか、調査したが、確認されていませんfq

6. 最新リリースでない場合は、アップグレードしてください。