CDH5 Solr性能調優方法是什么

這篇文章主要講解了“CDH5 Solr性能調優方法是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“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。

感謝各位的閱讀，以上就是“CDH5 Solr性能調優方法是什么”的內容了，經過本文的學習后，相信大家對CDH5 Solr性能調優方法是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！