CDH5 Solr性能調(diào)優(yōu)方法是什么

這篇文章主要講解了“CDH5 Solr性能調(diào)優(yōu)方法是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“CDH5 Solr性能調(diào)優(yōu)方法是什么”吧！

Solr性能調(diào)優(yōu)

Solr性能調(diào)優(yōu)是個(gè)復(fù)雜的過程，本文旨在描述Solr在使用過程中對性能優(yōu)化的注意事項(xiàng)。

在安裝完成之后的調(diào)優(yōu)

有些配置最好在安裝之后立馬修改，這樣可以避免修改配置之后需要重復(fù)索引。

配置一個(gè)必須的Lucene版本

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

1. <luceneMatchVersion>4.4</luceneMatchVersion>  

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

Schema設(shè)計(jì)

當(dāng)我們創(chuàng)建一個(gè)schema的時(shí)候，我們需要使用正確的數(shù)據(jù)類型來描述相應(yīng)的數(shù)據(jù)字段，譬如：

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

• 推薦使用text類型替代string類型來適應(yīng)系統(tǒng)語言環(huán)境。因?yàn)閠ext類型可以返回一個(gè)輸入條目的子集結(jié)果，譬如：當(dāng)我們查詢'John'的時(shí)候我們可能會(huì)找到'John Smith'的數(shù)據(jù)結(jié)果，如果是string類型的話，則僅僅只會(huì)返回匹配的結(jié)果。

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

一般性調(diào)優(yōu)

1.對于Faceting查詢來說啟動(dòng)facet.thread來指定多線程并發(fā)查詢，譬如：

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

上面就是配置100個(gè)線程來并發(fā)查詢，關(guān)于Faceting的具體用法可以參看：https://cwiki.apache.org/confluence/display/solr/Faceting

2.通過solr.hdfs.blockcache.slab.count參數(shù)配置HDFS的塊緩存數(shù)量，默認(rèn) 情況下一個(gè)HDFS塊緩存是128M，推薦使用物理內(nèi)存的10%~20%來配置count數(shù)，譬如一個(gè)50G內(nèi)存的機(jī)器，推薦使用5G~10G的內(nèi)存，那 么count的配置數(shù)量范圍為：5*1024/128~10*1024/128這個(gè)范圍內(nèi)即可。該參數(shù)在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會(huì)讀取系統(tǒng)配置的solr.hdfs.blockcache.slab.count參數(shù)，如果沒有配置該參數(shù)則默認(rèn)為1。該參數(shù)在Cloudera Manager中通過Solr->配置->Solr Server Default Group->資源管理下進(jìn)行修改調(diào)整。

3.增加了hdfs的塊緩存之后我們必須要增大JVM的內(nèi)存大小來避免OOM異常。如果是手動(dòng)安裝，我們需要在/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堆棧大小(字節(jié))和Solr 服務(wù)其的Java直接內(nèi)存大小(字節(jié))參數(shù)找到，以上是以50G的物理內(nèi)存作為標(biāo)準(zhǔn)，其中Xmx推薦配置為物理內(nèi)存的20%左右，MaxDirectMeorySize推薦配置為物理內(nèi)存的30%左右。

4.為了更好的提升性能，cloudera建議修改linxu的swap空間數(shù)，配置如下：

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.在不同的環(huán)境下選擇不同的GC機(jī)制能夠更好的提升Solr的性能，有如下2向GC機(jī)制可供選擇：

• Concurrent low pause collector:簡稱CMS，主要適用場景是對響應(yīng)時(shí)間的重 要性大于吞吐量的需求，能夠承受垃圾回收線程和應(yīng)用線程共享處理資源，并且應(yīng)用中存在比較多的長生命周期對象的應(yīng)用。主要是對年老代的回收，目標(biāo)是盡量減 少應(yīng)用的暫停時(shí)間，減少full gc發(fā)生的幾率，利用和應(yīng)用線程并發(fā)的垃圾回收線程來標(biāo)記清楚年老代。啟用CMS：-XX:+UseConcMarkSweepGC

• Throughput collector:追求最大吞吐量而設(shè)計(jì)的垃圾收集機(jī)制，主要采用并行收集算法對年輕代的收集。如果solr對吞吐量要求高于用戶體驗(yàn)，那么可以采用此機(jī)制，但是它通常會(huì)連接超時(shí)而影響用戶體驗(yàn)，啟用該機(jī)制：-XX:+UseParallelGC

CDH5默認(rèn)使用的CMS機(jī)制，修改可以在Solr->配置->Solr Server Default Group>高級->Solr Server的Java配置選項(xiàng)中修改其參數(shù)。

6.如果我們擁有多余的硬件資源，我們可以通過replica來提升查詢的吞吐量，當(dāng)然，添加replica會(huì)對第一個(gè)replica的寫入性能有稍微的影響，但是這應(yīng)該是最小的負(fù)面影響了。

7.solrconfig.xml文件中ramBufferSizeMB參數(shù)，表示在添加或者刪除文檔時(shí)，為了 減少頻繁的更新索引，solr會(huì)選擇緩存在內(nèi)存中，當(dāng)內(nèi)存中的文件大小大于該值則會(huì)更新到索引庫中，較大的值將消耗更多的內(nèi)存，我們需要確保該值低于 JVM的內(nèi)存值，當(dāng)然也不是越大越好，越大就意味著GC的時(shí)候越困難。由于CDH中是將索引寫入到HDFS中，我們這里ramBufferSizeMB的值應(yīng)該和上面solr.hdfs.blockcache.slab.count設(shè)置的值保持一致。如果solr.hdfs.blockcache.slab.count配置為4，那么該數(shù)值配置為4*128(HDFS默認(rèn)塊大小)。值得注意的是與該參數(shù)相對應(yīng)的還有一個(gè)maxBufferedDocs參數(shù)，該參數(shù)表示索引的數(shù)目超過配置的數(shù)值后就刷新到索引庫中，因?yàn)槲覀儾恢烂織l索引的具體數(shù)據(jù)大小，如果配置了此參數(shù)可能會(huì)導(dǎo)致ramBufferSizeMB參數(shù)失效，所以不推薦開啟此參數(shù)。

8.solrconfig.xml文件中maxIndexingThreads參數(shù)，表示索引時(shí)并發(fā)的最大線程數(shù)，當(dāng)索引數(shù)據(jù)時(shí)線程數(shù)超過該配置值，其它線程將處于等待狀態(tài)，該值和CPU處理能力有關(guān)，默認(rèn)值為8.

9.solrconfig.xml文件中的filterCache參數(shù)，表示用來緩存filter queries(也就是查詢參數(shù)fq)得到的數(shù)據(jù)集。查詢參數(shù)有2種，一種是q，另外一種是fq。如果fq存在，會(huì)先查詢fq中的數(shù)據(jù)，再查詢q中的數(shù) 據(jù)，最后取并集，當(dāng)我們做多參數(shù)查詢的時(shí)候，如果我們采用q參數(shù)查詢，這樣查詢命中率會(huì)很低，而且占用較多的內(nèi)存空間，我們可以對查詢進(jìn)行優(yōu)化，用fq的 形式來求2個(gè)數(shù)據(jù)的交集會(huì)很好的提示性能。filterCache啟用通過

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

參數(shù)來配置，其中class是基于LRU算法的緩存實(shí)現(xiàn)，如果cache的數(shù)據(jù)插入多查詢少那么使用solr.LRUCache;如果查詢多插入少 那么使用solr.FastLRUCache。size表示緩存中保存的最大數(shù)據(jù)條數(shù)，initialSize表示cache初始化時(shí)的大 小，autowarmCount表示當(dāng)切換SolrIndexSearcher時(shí)，可以對新SolrIndexSearcher做預(yù)熱處理。該參數(shù)表示從 舊的SolrIndexSearcher中取多少數(shù)據(jù)在新的SolrIndexSearcher中重新引用。如果是近實(shí)時(shí)搜索，不推薦開啟。0表示不開 啟。

10.solrconfig.xml文件中的useCompoundFile參數(shù),表示將一個(gè)段的多個(gè)文件合并 為唯一的文件，開啟此特性需要額外消耗大概7%~33%的索引時(shí)間，在3.6版本前默認(rèn)為true，之后默認(rèn)為false。當(dāng)然設(shè)置為false后要注意 配置linux進(jìn)程允許打開的文件數(shù)目是否有限制，如果有限制可以通過在ulimit參數(shù)修改。

10.啟動(dòng)本地shard優(yōu)先性，在請求中加入preferLocalShard=true來啟動(dòng)該特性。啟動(dòng)該特性后會(huì)優(yōu)先使用本地shard中存儲(chǔ)的數(shù)據(jù)，從而減少網(wǎng)絡(luò)IO的數(shù)據(jù)傳輸。

11.我們需要注意的是SolrCloud已經(jīng)做了讀寫分離，并且當(dāng)我們的寫入請求鏈接是replica的時(shí)候，replica會(huì)自動(dòng)把該請求轉(zhuǎn)發(fā)給leader，再由leader分發(fā)給其它replica。

感謝各位的閱讀，以上就是“CDH5 Solr性能調(diào)優(yōu)方法是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對CDH5 Solr性能調(diào)優(yōu)方法是什么這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！