olr 性能调优 NO_NORMS
indexed fields
indexed fields 的數(shù)量將會影響以下的一些性能：
- 索引時的時候的內(nèi)存使用量
- 索引段的合并時間
- 優(yōu)化時間
- 索引的大小
我們可以通過 將 omitNorms=“true” 來減少indexed fields數(shù)量增加所帶來的影響。
stored fields
Retrieving the stored fields 確實是一種開銷。這個開銷，受每個文檔所存儲的字節(jié)影響很大。每個文檔的所占用的空間越大，文檔就顯的更稀疏，這樣從硬盤中讀取數(shù)據(jù)，就需要更多的i/o操作（通常，我們在存儲比較大的域的時候，就會考慮這樣的事情，比如存儲一篇文章的文檔。）
可以考慮將比較大的域放到solr外面來存儲。如果你覺得這樣做會有些別扭的話，可以考慮使用壓縮的域，但是這樣會加重cpu在存儲和讀取域的時候的負(fù)擔(dān)。不過這樣卻是可以較少i/0的負(fù)擔(dān)。
如果，你并不是總是使用 stored fields 的話，可以使用stored field的延遲加載，這樣可以節(jié)省很多的性能，尤其是使用compressed field 的時候。
Configuration Considerations
mergeFactor
這個是合并因子，這個參數(shù)大概決定了segment(索引段)的數(shù)量。
合并因子這個值告訴lucene，在什么時候，要將幾個segment合并成為一個segment, 合并因子就像是一個數(shù)字系統(tǒng)的基數(shù)一樣。
比如說，如果你將合并因子設(shè)成10，那么每往索引中添加1000個文檔的時候，就會創(chuàng)建一個新的索引段。當(dāng)?shù)?0個大小為1000的索引段添加進(jìn)來的時候，這十個索引段就會被合并成一個大小為10，000的索引段。當(dāng)十個大小為10，000的索引段生成的時候，它們就會被合并成一個大小為100，000 的索引段。如此類推下去。
這個值可以在 solrconfig.xml 中的 *mainIndex*中設(shè)置。（不用管indexDefaults中設(shè)置）
mergeFactor Tradeoffs
較高的合并因子
- 會提高索引速度
- 較低頻率的合并，會導(dǎo)致 更多的索引文件，這會降低索引的搜索效率
較低的合并因子
- 較少數(shù)量的索引文件，能加快索引的搜索速度。
- 較高頻率的合并，會降低索引的速度。
Cache autoWarm Count Considerations
當(dāng)一個新的 searcher 打開的時候，它緩存可以被預(yù)熱，或者說使用從舊的searcher的緩存的數(shù)據(jù)來“自動加熱”。autowarmCount是這樣的一個參數(shù)，它表示從舊緩存中拷貝到新緩存中的對象數(shù)量。autowarmCount這個參數(shù)將會影響“自動預(yù)熱”的時間。有些時候，我們需要一些折中的考慮，seacher啟動的時間和緩存加熱的程度。當(dāng)然啦，緩存加熱的程度越好，使用的時間就會越長，但往往，我們并不希望過長的seacher啟動時間。這個autowarm 參數(shù)可以在solrconfig.xml文件中被設(shè)置。
詳細(xì)的配置可以參考solr的wiki。
Cache hit rate（緩存命中率）
我們可以通過solr的admin界面來查看緩存的狀態(tài)信息。提高solr緩存的大小往往是提高性能的捷徑。當(dāng)你使用面搜索的時候，你或許可以注意一下filterCache,這個是由solr實現(xiàn)的緩存。
?
Explicit Warming of Sort Fields
如果你有許多域是基于排序的，那么你可以在"newSearcher"和"firstSearcher"event listeners中添加一些明顯需要預(yù)熱的查詢，這樣FieldCache 就會緩存這部分內(nèi)容。
Optimization Considerations
優(yōu)化索引，是我們經(jīng)常會做的事情，比如，當(dāng)我們建立好索引，然后這個索引不會再變更的情況，我們就會做一次優(yōu)化了。
但，如果你的索引經(jīng)常會改變，那么你就需要好好的考慮下面的因素的。
- 當(dāng)越來越多的索引段被加進(jìn)索引，查詢的性能就會降低， lucene對索引段的數(shù)量有一個上限的限制，當(dāng)超過這個限制的時候，索引段可以自動合并成為一個。
- 在同樣沒有緩存的情況下，一個沒有經(jīng)過優(yōu)化的索引的性能會比經(jīng)過優(yōu)化的索引的性能少10%……
- 自動加熱的時間將會變長，因為它依賴于搜索。
- 優(yōu)化將會對索引的分發(fā)產(chǎn)生影響。
- 在優(yōu)化期間，文件的大小將會是索引的兩倍，不過最終將會回到它原來的大小，或者會更小一點。
優(yōu)化，會將所有的索引段合并成為一個索引段，所以，優(yōu)化這個操作其實可以幫助避免“too many files”這個問題，這個錯誤是由文件系統(tǒng)拋出的。
Updates and Commit Frequency Tradeoffs
如果從機(jī)太經(jīng)常從主機(jī)更新的話，從機(jī)的性能是會受到影響的。為了避免，由于這個問題而引起的性能下降，我們還必須了解從機(jī)是怎樣執(zhí)行更新的，這樣我們才能更準(zhǔn)確去調(diào)節(jié)一些相關(guān)的參數(shù)（commit的頻率，spappullers,autowarming/autocount）,這樣，從機(jī)的更新才不會太頻繁。
這里討論三個有關(guān)的參數(shù)：
- number/frequency of snapshots ----snapshot的頻率。
- snappullers 是? 在crontab中的，它當(dāng)然可以每秒一次、每天一次、或者其他的時間間隔一次運(yùn)行。它運(yùn)行的時候，只會下載slave上沒有的，并且最新的版本。
- Cache autowarming 可以在solrconfig.xml文件中配置。
如果，你想要的效果是頻繁的更新slave上的索引，以便這樣看起來比較像“實時索引”。那么，你就需要讓snapshot盡可能頻繁的運(yùn)行，然后也讓 snappuller頻繁的運(yùn)行。這樣，我們或許可以每5分鐘更新一次，并且還能取得不錯的性能，當(dāng)然啦，cach的命中率是很重要的，恩，緩存的加熱時間也將會影響到更新的頻繁度。
cache對性能是很重要的。一方面，新的緩存必須擁有足夠的緩存量，這樣接下來的的查詢才能夠從緩存中受益。另一方面，緩存的預(yù)熱將可能占用很長一段時間，尤其是，它其實是只使用一個線程，和一個cpu在工作。snapinstaller太頻繁的話，solr slave將會處于一個不太理想的狀態(tài)，可能它還在預(yù)熱一個新的緩存，然而一個更新的searcher被opern了。
怎么解決這樣的一個問題呢，我們可能會取消第一個seacher，然后去處理一個更新seacher，也即是第二個。然而有可能第二個seacher 還沒有被使用上的時候，第三個又過來了。看吧，一個惡性的循環(huán)，不是。當(dāng)然也有可能，我們剛剛預(yù)熱好的時候就開始新一輪的緩存預(yù)熱，其實，這樣緩存的作用壓根就沒有能體現(xiàn)出來。出現(xiàn)這種情況的時候，降低snapshot的頻率才是硬道理。
Query Response Compression
在有些情況下，我們可以考慮將solr xml response 壓縮后才輸出。如果response非常大，就會觸及NIc i/o限制。
當(dāng)然壓縮這個操作將會增加cpu的負(fù)擔(dān)，其實，solr一個典型的依賴于cpu處理速度的服務(wù)，增加這個壓縮的操作，將無疑會降低查詢性能。但是，壓縮后的數(shù)據(jù)將會是壓縮前的數(shù)據(jù)的6分之一的大小。然而solr的查詢性能也會有15%左右的消耗。
至于怎樣配置這個功能，要看你使用的什么服務(wù)器而定，可以查閱相關(guān)的文檔。
Embedded vs HTTP Post
使用embeded 來建立索引，將會比使用xml格式來建立索引快50%。
RAM Usage Considerations（內(nèi)存方面的考慮）
OutOfMemoryErrors
如果你的solr實例沒有被指定足夠多的內(nèi)存的話，java virtual machine也許會拋outof memoryError，這個并不對索引數(shù)據(jù)產(chǎn)生影響。但是這個時候，任何的 adds/deletes/commits操作都是不能夠成功的。
Memory allocated to the Java VM
最簡單的解決這個方法就是，當(dāng)然前提是java virtual machine 還沒有使用掉你全部的內(nèi)存，增加運(yùn)行solr的java虛擬機(jī)的內(nèi)存。
Factors affecting memory usage（影響內(nèi)存使用量的因素）
我想，你或許也會考慮怎樣去減少solr的內(nèi)存使用量。
其中的一個因素就是input document的大小。
當(dāng)我們使用xml執(zhí)行add操作的時候，就會有兩個限制。
- document中的field都是會被存進(jìn)內(nèi)存的，field有個屬性叫maxFieldLength，它或許能幫上忙。
- 每增加一個域，也是會增加內(nèi)存的使用的。
轉(zhuǎn)載于:https://www.cnblogs.com/SuperBing/archive/2013/01/30/2882801.html
總結(jié)
以上是生活随笔為你收集整理的olr 性能调优 NO_NORMS的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【原创】Performanced C++
- 下一篇： test0