Solr調優參考

共整理三部分，第一部分Solr常規處理，第二部分針對性性處理，前者比較通用，後者有侷限性。務必根據具體應用特性，具體調節參數，對比性能。第三部分
solr查詢相關的

具體應用須要全面去把控，各個因素一塊兒起做用。

第一部分<Solr常規的調優>
E文鏈接 http://wiki.apache.org/solr/SolrPerformanceFactors

Schema Design Considerations

indexed fields

   indexed fields 的數量將會影響如下的一些性能：

• 索引時的時候的內存使用量
• 索引段的合併時間
• 優化時間
• 索引的大小

    咱們能夠經過將omitNorms=「true」來減小indexed fields數量增長所帶來的影響。

stored fields

    Retrieving the stored fields 確實是一種開銷。這個開銷，受每一個文檔所存儲的字節影響很大。每一個文檔的所佔用的空間越大，文檔就顯的更稀疏，這樣從硬盤中讀取數據，就須要更多的i/o操做（一般，咱們在存儲比較大的域的時候，就會考慮這樣的事情，好比存儲一篇文章的文檔。）

    能夠考慮將比較大的域放到solr外面來存儲。若是你以爲這樣作會有些彆扭的話，能夠考慮使用壓縮的域，可是這樣會加劇cpu在存儲和讀取域的時候的負擔。不過這樣倒是能夠較少i/0的負擔。

    若是，你並非老是使用stored fields的話，可使用stored field的延遲加載，這樣可以節省不少的性能，尤爲是使用compressed field 的時候。

Configuration Considerations

mergeFactor

    這個是合併因子，這個參數大概決定了segment(索引段)的數量。

    合併因子這個值告訴lucene，在何時，要將幾個segment合併成爲一個segment, 合併因子就像是一個數字系統的基數同樣。

    好比說，若是你將合併因子設成10，那麼每往索引中添加1000個文檔的時候，就會建立一個新的索引段。當第10個大小爲1000的索引段添加進來的時候，這十個索引段就會被合併成一個大小爲10，000的索引段。當十個大小爲10，000的索引段生成的時候，它們就會被合併成一個大小爲100，000的索引段。如此類推下去。

   
這個值能夠在solrconfig.xml 中的
*mainIndex*中設置。（不用管indexDefaults中設置）

mergeFactor Tradeoffs

  較高的合併因子

•   會提升索引速度
•   較低頻率的合併，會致使更多的索引文件，這會下降索引的搜索效率

  較低的合併因子

•   較少數量的索引文件，能加快索引的搜索速度。
•   較高頻率的合併，會下降索引的速度。

HashDocSet Max Size Considerations

hashDocSet是solrconfig.xml中自定義優化選項,
使用在filters(docSets)
中，更小的sets，代表更小的內存消耗、遍歷、插入。

 
hashDocSet參數值最後基於索引文檔總數來定，索引集合越大，hashDocSet值也越大。

Calulate 0.005 of the total number of documents that you are going to store.  Try values on either ‘side’ of that value to arrive at the best query times.  When query times seem to plateau, and performance doesn’t show much difference between the higher number and the lower, use the higher.

Note: hashDocSet is no longer part of Solr as of version 1.4.0, see SOLR-1169.

Cache autoWarm Count Considerations

    當一個新的searcher 打開的時候，它緩存能夠被預熱，或者說使用從舊的searcher的緩存的數據來「自動加熱」。autowarmCount是這樣的一個參數，它表示從舊緩存中拷貝到新緩存中的對象數量。autowarmCount這個參數將會影響「自動預熱」的時間。有些時候，咱們須要一些折中的考慮，seacher啓動的時間和緩存加熱的程度。固然啦，緩存加熱的程度越好，使用的時間就會越長，但每每，咱們並不但願過長的seacher啓動時間。這個autowarm 參數能夠在solrconfig.xml文件中被設置。

   詳細的配置能夠參考solr的wiki。

Cache hit rate（緩存命中率）

    咱們能夠經過solr的admin界面來查看緩存的狀態信息。提升solr緩存的大小每每是提升性能的捷徑。當你使用面搜索的時候，你或許能夠注意一下filterCache,這個是由solr實現的緩存。

  
詳細的內容能夠參考solrCaching這篇wiki。

Explicit Warming of Sort Fields

      若是你有許多域是基於排序的，那麼你能夠在「newSearcher」和「firstSearcher」event
listeners中添加一些明顯須要預熱的查詢，這樣FieldCache 就會緩存這部份內容。

Optimization Considerations

    優化索引，是咱們常常會作的事情，好比，當咱們創建好索引，而後這個索引不會再變動的狀況，咱們就會作一次優化了。

    但，若是你的索引常常會改變，那麼你就須要好好的考慮下面的因素的。

• 當愈來愈多的索引段被加進索引，查詢的性能就會下降， lucene對索引段的數量有一個上限的限制，當超過這個限制的時候，索引段能夠自動合併成爲一個。
• 在一樣沒有緩存的狀況下，一個沒有通過優化的索引的性能會比通過優化的索引的性能少10%……
• 自動加熱的時間將會變長，由於它依賴於搜索。
• 優化將會對索引的分發產生影響。
• 在優化期間，文件的大小將會是索引的兩倍，不過最終將會回到它原來的大小，或者會更小一點。

    優化，會將全部的索引段合併成爲一個索引段，因此，優化這個操做其實能夠幫助避免「too many files」這個問題，這個錯誤是由文件系統拋出的。

Updates and Commit Frequency Tradeoffs

  
若是從機 常常從 主機更新的話，從機的性能是會受到影響的。爲了不，因爲這個問題而引發的性能降低，咱們還必須瞭解從機是怎樣執行更新的，這樣咱們才能更準確去調節一些相關的參數（commit的頻率，spappullers, autowarming/autocount）,這樣，從機的更新纔不會太頻繁。

1. 
   執行commit操做會讓solr新生成一個snapshot。若是將postCommit參數設成true的話，optimization也會執行snapShot.
2. slave上的Snappuller程序通常是在crontab上面執行的，它會去master詢問，有沒有新版的snapshot。一旦發現新的版本，slave就會把它下載下來，而後snapinstall.
3. 每次當一個新的searcher被open的時候，會有一個緩存預熱的過程，預熱以後，新的索引纔會交付使用。

   這裏討論三個有關的參數：

• number/frequency of snapshots  —-snapshot的頻率。
• snappullers 是 在crontab中的，它固然能夠每秒一次、天天一次、或者其餘的時間間隔一次運行。它運行的時候，只會下載slave上沒有的，而且最新的版本。
• Cache autowarming 能夠在solrconfig.xml文件中配置。

     若是，你想要的效果是頻繁的更新slave上的索引，以便這樣看起來比較像「實時索引」。那麼，你就須要讓snapshot儘量頻繁的運行，而後也讓snappuller頻繁的運行。這樣，咱們或許能夠每5分鐘更新一次，而且還能取得不錯的性能，固然啦，cach的命中率是很重要的，恩，緩存的加熱時間也將會影響到更新的頻繁度。

   cache對性能是很重要的。一方面，新的緩存必須擁有足夠的緩存量，這樣接下來的的查詢纔可以從緩存中受益。另外一方面，緩存的預熱將可能佔用很長一段時間，尤爲是，它實際上是隻使用一個線程，和一個cpu在工做。snapinstaller太頻繁的話，solr
slave將會處於一個不太理想的狀態，可能它還在預熱一個新的緩存，然而一個更新的searcher被opern了。

    怎麼解決這樣的一個問題呢，咱們可能會取消第一個seacher，而後去處理一個更新seacher，也便是第二個。然而有可能第二個seacher 尚未被使用上的時候，第三個又過來了。看吧，一個惡性的循環，不是。固然也有可能，咱們剛剛預熱好的時候就開始新一輪的緩存預熱，其實，這樣緩存的做用壓根就沒有能體現出來。出現這種狀況的時候，下降snapshot的頻率纔是硬道理。

Query Response Compression

    在有些狀況下，咱們能夠考慮將solr xml response 壓縮後才輸出。若是response很是大，就會觸及NIc i/o限制。

    固然壓縮這個操做將會增長cpu的負擔，其實，solr一個典型的依賴於cpu處理速度的服務，增長這個壓縮的操做，將無疑會下降查詢性能。可是，壓縮後的數據將會是壓縮前的數據的6分之一的大小。然而solr的查詢性能也會有15%左右的消耗。

  至於怎樣配置這個功能，要看你使用的什麼服務器而定，能夠查閱相關的文檔。

Embedded vs HTTP Post

使用embeded 來創建索引，將會比使用xml格式來創建索引快50%。

RAM Usage Considerations（內存方面的考慮）

OutOfMemoryErrors

    若是你的solr實例沒有被指定足夠多的內存的話，java virtual machine也許會拋outof memoryError，這個並不對索引數據產生影響。可是這個時候，任何的adds/deletes/commits操做都是不可以成功的。

Memory allocated to the Java VM

    最簡單的解決這個方法就是，固然前提是java virtual machine尚未使用掉你所有的內存，增長運行solr的java虛擬機的內存。

Factors affecting memory usage（影響內存使用量的因素）

我想，你或許也會考慮怎樣去減小solr的內存使用量。其中的一個因素就是input document的大小。當咱們使用xml執行add操做的時候，就會有兩個限制。

• document中的field都是會被存進內存的，field有個屬性叫maxFieldLength，它或許能幫上忙。
• 每增長一個域，也是會增長內存的使用的。

第二部分<Solr特殊調優>

1. 多core的時候

多core 若是同一時間進行core 切換，會致使內存、cpu壓力過大，能夠擴展Solr代碼，限制最多同時core
切換的執行個數。保證不會出現高load或者高cpu 風險

2，應用較高安全

最後不低於2個結點工做，而且最好2個結點是跨機器的。
offline與online切換的時候，若是數據量不是不少，能夠考慮index與search合一，若是數據量較大，超過5000w的時候，建議index
offline或者search結點以外的其餘結點上執行index

3.cache參數配置

若是更新很頻繁，致使commit和reopen頻繁，若是能夠的話，關閉cache.
若是訪問中依賴cache提示性能，那麼最好關閉cache warm，no facet 需求
或者開開啓cache warm  有facet須要，對fieldvalue cache很依賴的話。
實時更新的話，一般document cache命中率比較低，徹底能夠不開啓這個配置

4.reopen 和commit

若是能夠的話，主磁盤索引，不參入segment合併，新的索引段走不一樣的目錄。而且reopen的時候，主索引的不變更。

commit與reopen異步化

5.有一部分數據若是不變更，能夠考慮使用memory cache 或者locale cache 平衡性能和空間開銷，同時避免FGC

6.中間變量壓縮、單例化

全部查詢或者建索引過程當中，儘可能少建立對象，而經過set改變對象值，以及單例化，提高性能。一些較大中間變量，若是能夠的話，採起一些整數壓縮

7.對象表示重定義
例如日期、地區、url、byte等一些對象，能夠考慮差值、區位碼、可別部分、壓縮等結構，使得內存開銷下降間接使得內存使用率提升，得到更好性能。

8.index與store 隔離
就是index發揮它的查詢性能，store發揮它的存儲、響應性能。
也就是不要將全部的內容都放在index中，儘可能使得field的屬性stored=false

9. 使用solr、lucene最新版本

10. 共享分詞實例
自定義的分詞，務必使用單例。千萬不要一個document建立一個分詞對象

第三部分 Solr查詢

1. 對按指定域排序
展現的時候，對於數字的建議，展現最近1或者3個月數據。例如價格，防止做弊
dump或者建索引的時候，對數字加以上下界檢測，及早發現數字自己正確，而實際意義不合理的數據

2. 排序可變性
默認的排序務必有本身的相關參數，而且平衡各方面需求。
排序要變，可是不至於大的波動。排序的細節不公開，可是排序的結果能夠解釋的清楚。

3.線上線下
有些分值能夠線下完成，有些分值線上完成。看需求。

4.多域查詢
若是默認查詢多個域，不妨將多個域合成一個域，只差一個域

5.高亮
高亮能夠在solr裏面或者外面執行的，不必定在solr裏面執行，能夠在solr以外執行
同理，分詞能夠在線下執行好，dump只執行簡單的空格分詞便可

6.統計
facet統計能夠先上與線下相結合，不必定徹底依賴線上即時計數。

7.主動搜索 主動搜索查詢串務必嚴格處理，既要去無效查詢串，也要適當擴展查詢串。 明確查詢路徑和hit=0的對應處理。