CDH5 Solr性能調優

Solr性能調優

Solr性能調優是個複雜的過程，本文旨在描述Solr在使用過程當中對性能優化的注意事項。

在安裝完成以後的調優

有些配置最好在安裝以後立馬修改，這樣能夠避免修改配置以後須要重複索引。

配置一個必須的Lucene版本

配置一個咱們安裝的最新版本的Lucene版本，最新的版本將擁有最新的特性以及對一些已知bug的修復，推薦使用solr最新版的lucene版本，該配置在solrconfig.xml文件中修改。

 

1. <luceneMatchVersion>4.4</luceneMatchVersion>  

CDH5.3.2中Solr使用的Lucene版本是4.4，推薦不要修改此內容。

 

Schema設計

當咱們建立一個schema的時候，咱們須要使用正確的數據類型來描述相應的數據字段，譬如：

• 使用tdate數據類型來描述日期類型，而不是使用string類型的日期。

• 推薦使用text類型替代string類型來適應系統語言環境。由於text類型能夠返回一個輸入條目的子集結果，譬如：當咱們查詢'John'的時候咱們可能會找到'John Smith'的數據結果，若是是string類型的話，則僅僅只會返回匹配的結果。

• 對於IDs字段，使用string類型。

通常性調優

1.對於Faceting查詢來講啓動facet.thread來指定多線程併發查詢，譬如：

 

1. http://localhost:8983/solr/collection1/select?q=*:*&facet=true&fl=id&facet.field=f0_ws&facet.threads=100  

上面就是配置100個線程來併發查詢，關於Faceting的具體用法能夠參看：https://cwiki.apache.org/confluence/display/solr/Faceting

 

2.經過solr.hdfs.blockcache.slab.count參數配置HDFS的塊緩存數量，默認 狀況下一個HDFS塊緩存是128M，推薦使用物理內存的10%~20%來配置count數，譬如一個50G內存的機器，推薦使用5G~10G的內存，那 麼count的配置數量範圍爲：5*1024/128~10*1024/128這個範圍內便可。該參數在solrconfig.xml文件中引用，具體如 下：

 

1. <directoryFactory name="DirectoryFactory">  

2.     <bool name="solr.hdfs.blockcache.enabled">${solr.hdfs.blockcache.enabled:true}</bool>  

3.     <int name="solr.hdfs.blockcache.slab.count">${solr.hdfs.blockcache.slab.count:1}</int>  

4.     <bool name="solr.hdfs.blockcache.direct.memory.allocation">${solr.hdfs.blockcache.direct.memory.allocation:true}</bool>  

5.     <int name="solr.hdfs.blockcache.blocksperbank">${solr.hdfs.blockcache.blocksperbank:16384}</int>  

6.     <bool name="solr.hdfs.blockcache.read.enabled">${solr.hdfs.blockcache.read.enabled:true}</bool>  

7.     <bool name="solr.hdfs.blockcache.write.enabled">${solr.hdfs.blockcache.write.enabled:true}</bool>  

8.     <bool name="solr.hdfs.nrtcachingdirectory.enable">${solr.hdfs.nrtcachingdirectory.enable:true}</bool>  

9.     <int name="solr.hdfs.nrtcachingdirectory.maxmergesizemb">${solr.hdfs.nrtcachingdirectory.maxmergesizemb:16}</int>  

10.     <int name="solr.hdfs.nrtcachingdirectory.maxcachedmb">${solr.hdfs.nrtcachingdirectory.maxcachedmb:192}</int>  

11. </directoryFactory>  

 

其中solr.hdfs.blockcache.slab.count會讀取系統配置的solr.hdfs.blockcache.slab.count參數，若是沒有配置該參數則默認爲1。該參數在Cloudera Manager中經過Solr->配置->Solr Server Default Group->資源管理下進行修改調整。

3.增長了hdfs的塊緩存以後咱們必需要增大JVM的內存大小來避免OOM異常。若是是手動安裝，咱們須要在/etc/default /solr(若是是parcel模式下安裝的話目錄在/opt/cloudera/parcel/CDH-*/etc/default/solr)下增長 以下配置：

 

1. CATALINA_OPTS="-Xmx10g -XX:MaxDirectMemorySize=15g -XX:+UseLargePages -Dsolr.hdfs.blockcache.slab.count=60"  

若是是經過Cloudera Manager能夠經過Solr->配置->Solr Server Default Group->資源管理下Solr Server

 

 的Java堆棧大小(字節)和Solr 服務其的Java直接內存大小(字節)參數找到，以上是以50G的物理內存做爲標準，其中Xmx推薦配置爲物理內存的20%左右，MaxDirectMeorySize推薦配置爲物理內存的30%左右。

4.爲了更好的提高性能，cloudera建議修改linxu的swap空間數，配置以下：

 

1. # minimize swappiness  

2. sudo sysctl vm.swappiness=10  

3. sudo bash -c 'echo "vm.swappiness=10">> /etc/sysctl.conf'  

4. # disable swap space until next reboot:  

5. sudo /sbin/swapoff -a  

5.在不一樣的環境下選擇不一樣的GC機制可以更好的提高Solr的性能，有以下2向GC機制可供選擇：

 

• Concurrent low pause collector:簡稱CMS，主要適用場景是對響應時間的重 要性大於吞吐量的需求，可以承受垃圾回收線程和應用線程共享處理資源，而且應用中存在比較多的長生命週期對象的應用。主要是對年老代的回收，目標是儘可能減 少應用的暫停時間，減小full gc發生的概率，利用和應用線程併發的垃圾回收線程來標記清楚年老代。啓用CMS：-XX:+UseConcMarkSweepGC

• Throughput collector:追求最大吞吐量而設計的垃圾收集機制，主要採用並行收集算法對年輕代的收集。若是solr對吞吐量要求高於用戶體驗，那麼能夠採用此機制，可是它一般會鏈接超時而影響用戶體驗，啓用該機制：-XX:+UseParallelGC

CDH5默認使用的CMS機制，修改能夠在Solr->配置->Solr Server Default Group>高級->Solr Server的Java配置選項中修改其參數。

6.若是咱們擁有多餘的硬件資源，咱們能夠經過replica來提高查詢的吞吐量，固然，添加replica會對第一個replica的寫入性能有稍微的影響，可是這應該是最小的負面影響了。

7.solrconfig.xml文件中ramBufferSizeMB參數，表示在添加或者刪除文檔時，爲了 減小頻繁的更新索引，solr會選擇緩存在內存中，當內存中的文件大小大於該值則會更新到索引庫中，較大的值將消耗更多的內存，咱們須要確保該值低於 JVM的內存值，固然也不是越大越好，越大就意味着GC的時候越困難。因爲CDH中是將索引寫入到HDFS中，咱們這裏ramBufferSizeMB的值應該和上面solr.hdfs.blockcache.slab.count設置的值保持一致。若是solr.hdfs.blockcache.slab.count配置爲4，那麼該數值配置爲4*128(HDFS默認塊大小)。值得注意的是與該參數相對應的還有一個maxBufferedDocs參數，該參數表示索引的數目超過配置的數值後就刷新到索引庫中，由於咱們不知道每條索引的具體數據大小，若是配置了此參數可能會致使ramBufferSizeMB參數失效，因此不推薦開啓此參數。

8.solrconfig.xml文件中maxIndexingThreads參數，表示索引時併發的最大線程數，當索引數據時線程數超過該配置值，其它線程將處於等待狀態，該值和CPU處理能力有關，默認值爲8.

9.solrconfig.xml文件中的filterCache參數，表示用來緩存filter queries(也就是查詢參數fq)獲得的數據集。查詢參數有2種，一種是q，另一種是fq。若是fq存在，會先查詢fq中的數據，再查詢q中的數 據，最後取並集，當咱們作多參數查詢的時候，若是咱們採用q參數查詢，這樣查詢命中率會很低，並且佔用較多的內存空間，咱們能夠對查詢進行優化，用fq的 形式來求2個數據的交集會很好的提示性能。filterCache啓用經過

 

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

 

參數來配置，其中class是基於LRU算法的緩存實現，若是cache的數據插入多查詢少那麼使用solr.LRUCache;若是查詢多插入少 那麼使用solr.FastLRUCache。size表示緩存中保存的最大數據條數，initialSize表示cache初始化時的大 小，autowarmCount表示當切換SolrIndexSearcher時，能夠對新SolrIndexSearcher作預熱處理。該參數表示從 舊的SolrIndexSearcher中取多少數據在新的SolrIndexSearcher中從新引用。若是是近實時搜索，不推薦開啓。0表示不開 啓。

10.solrconfig.xml文件中的useCompoundFile參數,表示將一個段的多個文件合併 爲惟一的文件，開啓此特性須要額外消耗大概7%~33%的索引時間，在3.6版本前默認爲true，以後默認爲false。固然設置爲false後要注意 配置linux進程容許打開的文件數目是否有限制，若是有限制能夠經過在ulimit參數修改。

10.啓動本地shard優先性，在請求中加入preferLocalShard=true來啓動該特性。啓動該特性後會優先使用本地shard中存儲的數據，從而減小網絡IO的數據傳輸。

11.咱們須要注意的是SolrCloud已經作了讀寫分離，而且當咱們的寫入請求連接是replica的時候，replica會自動把該請求轉發給leader，再由leader分發給其它replica。

12.對於本地solr性能優化能夠參看：http://wiki.apache.org/lucene-java/ImproveIndexingSpeed