Solr Cache最佳實踐幫你輕鬆調優

1、背景

Apache Solr是被普遍使用的開源搜索引擎，Greenplum DB的全文檢索組件Greenplum Text就是基於其構建的：Greenplum Text簡寫爲GPText，它將Greenplum數據庫與Apache SolrCloud企業搜索和MADlib分析庫進行緊密集成，從而爲客戶提供了大規模分析處理和業務決策支持，主要功能包括免費的文本搜索以及對文本分析的支持。

廣義來講，solr中的cache能夠分爲2大部分：solr系統的內部cache和留給操做系統的文件cache。對於前者來講，若是設置不當，不但不會提高性能，還將浪費大量內存。

根據長期爲客戶調優的經驗，本文做者將對solr cache進行簡要介紹並陳述solr cache最佳實踐。

2、分類

solr內部cache分爲4類：

• QueryResult Cache：緩存query對應的docid拉鍊，數據結構：query => docid list
• Filter Cache：緩存filter對應的bitmap索引，數據結構：filter => bitmap (total doc number bit)
• Doc Cache：緩存doc id對應的stored的doc文檔內容，數據結構：doc id => doc content
• Custom Cache，自定義cache，默認關閉，本文檔中再也不介紹。

你們須要留意的是這裏給出的數據結構只是樸素實現，而solr實際的內部實現比樸素實現更精良（如節省內存），特別是對於filter cache，詳見solr社區討論。

3、配置

在每一個索引的solrconfig.xml中配置，配置每類索引的最大個數（size），舉例：

<filterCache class="solr.FastLRUCache" size="512" initialSize="512" autowarmCount="0" />

<queryResultCache class="solr.LRUCache" size="512" initialSize="512" autowarmCount="0" />

<documentCache class="solr.LRUCache" size="512" initialSize="512" autowarmCount="0" />

關於配置，你們須要留意2點內容：

• 前2者還能夠設置maxRamMB參數（版本要求：solr 6.6中不能配置，7.3.1能夠）：該類cache的使用內存上限，單位是MB。若是配置了它的話，size和initialSize參數將被忽略
• 另外cache的生效時間受到auto/autosoft commit參數的影響，目前最新gptext代碼中配置以下，autocommit不會致使cache失效（由於設置了opensearcher爲false）

<autoCommit>

<maxDocs>10000</maxDocs>

<maxTime>60000</maxTime>

<openSearcher>false</openSearcher>
</autoCommit>

autosoftcommit致使cache失效：每Docs/Time個週期到了會致使cache失效

<autoSoftCommit>

<maxDocs>100000</maxDocs>

<maxTime>600000</maxTime>

</autoSoftCommit>

4、內存開銷

這裏咱們經過一個例子來進行說明，假設某用戶的一個使用場景以下：

• 每一個query/filter 10 Byte
• 平均結果數目：25萬條（每條結果id使用一個8byte整數表明）
• 總文檔數目：10億（使用一個bitmap，每一個文檔佔1bit）
• 平均stored文檔大小：32 Byte（4個8byte字段）
• cache和autocommit參數都是默認值

能夠得出每類cache的最大大小：

• queryresult cache：(10+2500008) 512 = 1GB （最差狀況下）
• filter cache：(1000000000/8) * 512 = 60GB （最差狀況下）
• doc cache：32 * 512 = 16KB

明顯可見filter cache過大，不過以上只是定性分析，便於找出可能的內存瓶頸，實際的內存開銷會更小。

5、監控
若是能夠訪問SOLR UI，能夠查看每一個core上的cache metrics統計：

http://localhost:18983/solr/#/demo.public.test_wiki_shard1_replica_n2/plugins?type=cache

若是沒法訪問SOLR UI，直接經過以下url查看：

• http://localhost:18983/solr/admin/metrics?group=core&prefix=CACHE.searcher.queryResultCache
• http://localhost:18983/solr/admin/metrics?group=core&prefix=CACHE.searcher.filterCache
• http://localhost:18983/solr/admin/metrics?group=core&prefix=CACHE.searcher.documentCache

例如，經過SOLR UI查看metrics項目

重點關注須要XXX.cumulative_hitratio：它是solr節點啓動後積累的命中率，不會受到cache清空致使的影響。

6、配置實踐

本文將要給出每類cache size的通用設置方法：

首先，持續運行系統一段時間（如一天/一週等），而後蒐集以下系統參數：1. 是否發生了OOM (out of memory) 2. 蒐集每一個索引的cumulative_hitratio（一般只須要關注最大的索引）

若是未發生OOM，請按照以下流程圖來處理：

若是發生了OOM，咱們就應該關閉或限制某類cache的大小：

1.filter cache

• 如前文中實例，通常它是對空間需求最高的cache類型，OOM極可能是由它致使
• 檢查cumulative_hitratioa. 若是高（代表cache很是有效），爲它設置一個能接受的maxRamMB值b. 若是低，直接關閉（設置size爲0）

2. query result cache

• 一般不該該關閉它（每每能發揮做用，如重複搜索一個query）值
• 檢查cumulative_hitratioa. 若是高，爲它設置一個能接受的maxRamMBb. 若是低，設置一個較小的maxRamMB值

3. document cache

一般狀況下不是內存瓶頸，所以請首先處理好前2類cache

7、參考

• https://teaspoon-consulting.c...
• Scaling Lucene and Solr：https://lucidworks.com/post/s...
• https://blog.cloudera.com/apa...
• https://blog.cloudera.com/sol...
• https://lucene.apache.org/sol...
• https://blog.csdn.net/john_ho...