Solr本身的性能不錯(cuò)，但是在使用過程中，還是會(huì)遇到一些使用錯(cuò)誤，或是沒考慮到的地方；在出現(xiàn)瓶頸時(shí)，可以首先考慮哪些點(diǎn)呢？下面就來看一下Solr官方的總結(jié)，個(gè)人覺得總結(jié)的很好。SOLR+LUCENE的官網(wǎng)還是挺給力的?

對Schema設(shè)計(jì)的考慮
索引域的數(shù)量增長會(huì)很大程度的影響以下的內(nèi)容：
?

引用 索引期間的內(nèi)存使用
段的合并時(shí)間
優(yōu)化(optimization)時(shí)間

如果設(shè)置omitNorms="true" ，則可以減小對這些影響
批注：如果設(shè)置Norms，則會(huì)影響評分的標(biāo)準(zhǔn)，但會(huì)大大的增大索引文件的大小，如果對該字段沒有需求，建議關(guān)掉


存儲(chǔ)域
通過查詢結(jié)果獲取存儲(chǔ)域的值是一個(gè)相當(dāng)大的開銷。如果文檔的數(shù)據(jù)特別大，或者一些數(shù)據(jù)存儲(chǔ)到了分布式的磁盤中（需要更多的IO來查詢域）時(shí)，那么花費(fèi)將會(huì)很大。這在存儲(chǔ)大數(shù)據(jù)時(shí)很容易被考慮到，尤其是整個(gè)文檔內(nèi)容的存儲(chǔ)。

考慮將大數(shù)據(jù)的存儲(chǔ)放到solr之外。如果非要這么做，那么可以考慮使用壓縮域，這將會(huì)用CPU的開銷來換取IO的開銷。

如果你并不需要使用所有的存儲(chǔ)域，允許延遲加載(enableLazyFieldLoading)將會(huì)是很好的方式，由于是對那些壓縮的字段。

批注：延遲加載在查詢期間很有用，尤其是需要對某些字段作額外的處理時(shí)，它既能減少內(nèi)存使用，又加速了程序的處理。另外，盡量減小索引的大小絕對不是壞事。

SOLR配置考慮

mergeFactor

mergeFactor大致決定了段的數(shù)量。mergeFactor的值告訴lucene有多少個(gè)段需要進(jìn)行合并。它可以被認(rèn)為是一個(gè)基本的數(shù)量系統(tǒng)。

舉個(gè)例子，如果你設(shè)置mergeFactor為10，每1000個(gè)文檔時(shí)會(huì)創(chuàng)建一個(gè)新的段到硬盤中。當(dāng)?shù)?0個(gè)段被添加時(shí)，所有的10個(gè)段將被合并為1個(gè)段 (包含10000個(gè)文檔)；當(dāng)這樣的10個(gè)文檔被創(chuàng)建時(shí)，它們又會(huì)被合并為個(gè)包含100,000個(gè)文檔的段，依次類推（當(dāng)然也有上限）。這樣，在任何時(shí)候，都不會(huì)有多余9個(gè)的段(相同索引大小情況下)存在。

該值在solrconfig.xml中的mainIndex設(shè)置(它會(huì)忽略indexDefaults)。
批注：關(guān)于合并的策略，請看我之前的博客：lucene內(nèi)部的合并策略

mergeFactor Tradeoffs
高值的merge factor(比如25)：

引用 Pro：一般會(huì)加快索引的速度
Con：低合并延遲，在查詢時(shí)需要搜索更多的文件，所以會(huì)使查詢變慢

低值的merge factor(比如2)：

引用 Pro：更少的索引文件，加快查詢的速度
Con：更多的文件合并，將使索引變慢

批注：一般來說不需要這么極端，設(shè)10即可。保證讀速度的同時(shí)，也保證合并的速度。

HashDocSet最大值的考慮
SOLR1.4之后不支持了，不再描述。

cache中autoWarm數(shù)量的考慮
當(dāng)一個(gè)新的searcher被打開時(shí)，它的cache可以從舊的searcher中重新加載或者自動(dòng)預(yù)熱(autowarmd)緩存的對象。autowarmCount是將被拷貝到新searcher中的對象的數(shù)量，你需要根據(jù)autowarm的時(shí)間來設(shè)置autowarmCount。如何使用autowarmCount，需要你根據(jù)時(shí)間和數(shù)量來設(shè)定。

批注：autoWarm即新的searcher會(huì)有多少數(shù)據(jù)被緩存，如果沒有緩存，一些熱點(diǎn)數(shù)據(jù)無疑會(huì)變得很慢。所以，合理的這是這個(gè)值，能大大加快查詢的效率。


緩存命中率
在Solr的admin中監(jiān)控緩存的統(tǒng)計(jì)。增加緩存的大小通常是提高性能的最好方法，尤其是你對一個(gè)指定的緩存類型作逐出操作時(shí)。請關(guān)注filterCache，它也被用來作solr的facetting。

批注：一個(gè)典型的場景是范圍查詢，類似fl=price:[100 TO 200]這樣的情況，將數(shù)據(jù)該范圍存儲(chǔ)起來時(shí)，對其他的一些查詢都可以復(fù)用這個(gè)緩存的數(shù)據(jù)，很高效。

對排序的域作明確的預(yù)熱
如果你的工作大多基于排序的方式，那么你最好在“newSearcher”和“firstSearcher”時(shí)間監(jiān)聽器中添加明確的預(yù)熱查詢規(guī)則，這樣FiledCache可以在用戶的查詢被執(zhí)行前就將數(shù)據(jù)加載。

優(yōu)化的考慮
你可能想在任何時(shí)候都可以優(yōu)化你的索引。比如你創(chuàng)建索引后，就沒有修改過它。

如果你的索引收到了一串需要更新的流，那么請考慮以下的因素：

引用
1. 如果過多的段被添加到索引中，那么查詢的性能將會(huì)下降；lucene的段自動(dòng)合并能將段的數(shù)量控制在一定范圍
2. auto-warming的時(shí)間也會(huì)延長，它通常依賴于所做的查詢
3. 優(yōu)化后的第一次分布耗時(shí)比之后的分布耗時(shí)要長。具體請看Collection Distribution
4. 在優(yōu)化期間索引的問題大小會(huì)加倍，優(yōu)化后會(huì)回到原始大小或更小
5. 如果可以，請確保沒有并發(fā)的commit請求，否則會(huì)有很大的性能損失

在優(yōu)化時(shí)所有的索引會(huì)放到唯一的段中；優(yōu)化索引會(huì)避免“文件打開數(shù)過多”的問題。
這里有一篇關(guān)于該問題的文章：ONJava Article

更新和提交的頻率
如果slaves收到的數(shù)據(jù)過頻，那么性能必然受損。為了避免這個(gè)問題，你必須了解slaver的更新機(jī)制，這樣你才能更好的調(diào)整相關(guān)的參數(shù)（commit的數(shù)量/頻率、snappullers、autowarming/autocount）以使新數(shù)據(jù)的寫入不會(huì)那么頻繁。

引用 1. 集合的快照會(huì)在客戶端運(yùn)行commit時(shí)建立，或者在optimization時(shí)；這依賴于在master上的postCommit或postOptimize的鉤子方法
2. slaver上的Snappuller會(huì)運(yùn)行corn去檢查master上是否有新的快照，如果它找到新的版本，就會(huì)把它拿過來并install這些新的數(shù)據(jù)。
3. 當(dāng)一個(gè)新的searcher被打開時(shí)，autowarming會(huì)先于Solr的查詢請求之前完成。有了預(yù)熱的緩存，查詢的延遲將會(huì)小很多。

這里有三個(gè)相關(guān)的參數(shù)：

引用 快照的數(shù)量/頻率：這取決于客戶端的索引。因此，集合的版本號依賴于客戶端的活躍度
snappluller：基于cron，他可以精確到秒級別。它們運(yùn)行時(shí)，會(huì)獲取最近它們沒有的集合
緩存預(yù)熱：在solrconfig.xml中配置

查詢響應(yīng)的壓縮
在Solr返回xml應(yīng)答給客戶端之前對其進(jìn)行壓縮有時(shí)是值得做的。如果應(yīng)答結(jié)果非常大，或者網(wǎng)絡(luò)IO有限制，或者沒有千兆網(wǎng)卡，請考慮使用壓縮機(jī)制。

壓縮會(huì)增加CPU的使用，并且Solr本身也是CPU密集型的應(yīng)用，所以壓縮會(huì)降低查詢的性能。壓縮會(huì)使文件減小到1/6的大小，使網(wǎng)絡(luò)包減小到1/3的大小；相對的，查詢的性能會(huì)降低15%左右。

請查看你的應(yīng)用服務(wù)器的相關(guān)文檔（tomcat、resion、jetty...）來獲取關(guān)于壓縮的信息。

索引的性能
一般情況下，一次更新多個(gè)文檔比一個(gè)一個(gè)更新要快。

對于這種塊級的更新方式，考慮使用StreamingUpdateSolrServer.java，它提供多線程多連接的方式來更新流數(shù)據(jù)。
批注：StreamingUpdateSolrServer類相對CommonsHttpSolrServer要快很多，主要在于它將原本單個(gè)的文檔寫入變?yōu)榱伺繉懭?#xff0c;加上多線程多連接的方式，性能上快了超多。我們的測試數(shù)據(jù)表明，至少要快4-6倍以上。

內(nèi)存使用的考慮

OutOfMemoryErrors

如果你的solr實(shí)例沒有足夠的內(nèi)存，那么JVM有時(shí)會(huì)拋出OutOfMemoryErrors。這并不會(huì)對數(shù)據(jù)有影響，并且solr也會(huì)試圖優(yōu)美的恢復(fù)它。任何 添加/刪除/提交 的命令在異常拋出時(shí)都可能不成功；其他不利的影響也可能會(huì)產(chǎn)生。對應(yīng)用而言，如果SimpleFSLock 的鎖機(jī)制在使用的話，OutOfMemoryError 會(huì)導(dǎo)致solr丟失這個(gè)鎖。如果這發(fā)生了，更新索引的結(jié)果將會(huì)是這樣的異常：

Java代碼 ?

SEVERE:?Exception?during?commit/optimize:java.io.IOException:?Lock?obtain?timed?out:?SimpleFSLock@/tmp/lucene-5d12dd782520964674beb001c4877b36-write.lock??

SEVERE: Exception during commit/optimize:java.io.IOException: Lock obtain timed out: SimpleFSLock@/tmp/lucene-5d12dd782520964674beb001c4877b36-write.lock

如果你想在OOM時(shí)看堆的情況，請?jiān)O(shè)置"-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/the/dump"

JVM內(nèi)存的分配
針對這個(gè)錯(cuò)誤的最簡單方法，在JVM并沒有完全使用你的物理內(nèi)存時(shí)，考慮加大JVM的內(nèi)存容量：

Java代碼 ?

java?-Xms512M?-Xmx1024M?-jar?start.jar??

java -Xms512M -Xmx1024M -jar start.jar

影響內(nèi)存使用的因素

你可能想去減小solr的內(nèi)存使用。

一個(gè)方式就是減小文檔的大小。

當(dāng)運(yùn)行add命令時(shí)，標(biāo)準(zhǔn)的xml更新請求會(huì)有兩個(gè)限制：

引用 1. 所有的文檔必須同時(shí)放入到內(nèi)存中。通常，它的取值為sum(域的實(shí)際長度，maxFieldLength)。所以，調(diào)整maxFieldLength的大小可能會(huì)有幫助
2. 每個(gè)<field>...</field>標(biāo)簽都必須放入到內(nèi)存中，而不管maxFieldLength

注意一些不同的add請求會(huì)在不同的線程中并發(fā)運(yùn)行。越多的線程，就會(huì)導(dǎo)致越多的內(nèi)存使用。


我的一些其他使用經(jīng)驗(yàn)：
1.schema中的類型定義很重要，它直接影響了索引的性能
2.盡量少用filter，雖然它很好用，但是其hashSet的數(shù)量如果過多，很容易o(hù)om
3. cache的類，都用FastLRUCache吧，LRUCache還有鎖，太慢了
4. 通過docId取doc的過程看似平常，但是量大了就是一個(gè)災(zāi)難，在這點(diǎn)需要根據(jù)實(shí)際場景考慮
5. 能用緩存的用緩存，不能用緩存的，嘗試使用MMapDirectoryFactory，最好是SSD硬盤
6.其他，待想到了再補(bǔ)充

轉(zhuǎn)載于:https://www.cnblogs.com/cuihongyu3503319/p/10758010.html

總結(jié)

以上是生活随笔為你收集整理的影响solr性能的一些因素（附使用经验）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。