這篇文章主要講解了“CDH5 Solr性能調(diào)優(yōu)方法是什么”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“CDH5 Solr性能調(diào)優(yōu)方法是什么”吧！
為贛榆等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及贛榆網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為成都網(wǎng)站制作、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、贛榆網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！
Solr性能調(diào)優(yōu)是個(gè)復(fù)雜的過程，本文旨在描述Solr在使用過程中對(duì)性能優(yōu)化的注意事項(xiàng)。
有些配置最好在安裝之后立馬修改，這樣可以避免修改配置之后需要重復(fù)索引。
配置一個(gè)我們安裝的最新版本的Lucene版本，最新的版本將擁有最新的特性以及對(duì)一些已知bug的修復(fù)，推薦使用solr最新版的lucene版本，該配置在solrconfig.xml文件中修改。
CDH5.3.2中Solr使用的Lucene版本是4.4，推薦不要修改此內(nèi)容。
當(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é)果。
對(duì)于IDs字段，使用string類型。
1.對(duì)于Faceting查詢來說啟動(dòng)facet.thread來指定多線程并發(fā)查詢，譬如：
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文件中引用，具體如 下：
其中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)下增加 如下配置：
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ù)，配置如下：
# minimize swappiness
sudo sysctl vm.swappiness=10
sudo bash -c 'echo "vm.swappiness=10">> /etc/sysctl.conf'
# disable swap space until next reboot:
sudo /sbin/swapoff -a
5.在不同的環(huán)境下選擇不同的GC機(jī)制能夠更好的提升Solr的性能，有如下2向GC機(jī)制可供選擇：
Concurrent low pause collector:簡(jiǎn)稱CMS，主要適用場(chǎng)景是對(duì)響應(yīng)時(shí)間的重 要性大于吞吐量的需求，能夠承受垃圾回收線程和應(yīng)用線程共享處理資源，并且應(yīng)用中存在比較多的長(zhǎng)生命周期對(duì)象的應(yīng)用。主要是對(duì)年老代的回收，目標(biāo)是盡量減 少應(yīng)用的暫停時(shí)間，減少full gc發(fā)生的幾率，利用和應(yīng)用線程并發(fā)的垃圾回收線程來標(biāo)記清楚年老代。啟用CMS：-XX:+UseConcMarkSweepGC
Throughput collector:追求最大吞吐量而設(shè)計(jì)的垃圾收集機(jī)制，主要采用并行收集算法對(duì)年輕代的收集。如果solr對(duì)吞吐量要求高于用戶體驗(yàn)，那么可以采用此機(jī)制，但是它通常會(huì)連接超時(shí)而影響用戶體驗(yàn)，啟用該機(jī)制：-XX:+UseParallelGC
CDH5默認(rèn)使用的CMS機(jī)制，修改可以在Solr->配置->Solr Server Default Group>高級(jí)->Solr Server的Java配置選項(xiàng)中修改其參數(shù)。
6.如果我們擁有多余的硬件資源，我們可以通過replica來提升查詢的吞吐量，當(dāng)然，添加replica會(huì)對(duì)第一個(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ù)相對(duì)應(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)存空間，我們可以對(duì)查詢進(jìn)行優(yōu)化，用fq的 形式來求2個(gè)數(shù)據(jù)的交集會(huì)很好的提示性能。filterCache啟用通過
參數(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í)，可以對(duì)新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)先性，在請(qǐng)求中加入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)我們的寫入請(qǐng)求鏈接是replica的時(shí)候，replica會(huì)自動(dòng)把該請(qǐng)求轉(zhuǎn)發(fā)給leader，再由leader分發(fā)給其它replica。
感謝各位的閱讀，以上就是“CDH5 Solr性能調(diào)優(yōu)方法是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)CDH5 Solr性能調(diào)優(yōu)方法是什么這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！
重慶分公司
重慶分公司
