solr性能調優

時間 2019-11-20

標籤 solr 性能欄目系統性能简体版

原文原文鏈接

Schema Design Considerations

indexed fields

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

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

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

stored fields

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

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

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

Configuration Considerations

mergeFactor

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

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

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

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

mergeFactor Tradeoffs

較高的合併因子spa

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

較低的合併因子

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

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）,這樣，從機的更新纔不會太頻繁。

執行commit操做會讓solr新生成一個snapshot。若是將postCommit參數設成true的話，optimization也會執行snapShot.
slave上的Snappuller程序通常是在crontab上面執行的，它會去master詢問，有沒有新版的snapshot。一旦發現新的版本，slave就會把它下載下來，而後snapinstall.
每次當一個新的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的頻率纔是硬道理。