indexed fields

indexed fields 的數(shù)量將會(huì)影響以下的一些性能：

• 索引時(shí)的時(shí)候的內(nèi)存使用量
• 索引段的合并時(shí)間
• 優(yōu)化時(shí)間
• 索引的大小

我們可以通過 將 omitNorms=“true” 來減少indexed fields數(shù)量增加所帶來的影響。

stored fields

Retrieving the stored fields 確實(shí)是一種開銷。這個(gè)開銷，受每個(gè)文檔所存儲(chǔ)的字節(jié)影響很大。每個(gè)文檔的所占用的空間越大，文檔就顯的更稀疏，這樣從硬盤中讀取數(shù)據(jù)，就需要更多的i/o操作（通常，我們在存儲(chǔ)比較大的域的時(shí)候，就會(huì)考慮這樣的事情，比如存儲(chǔ)一篇文章的文檔。）

可以考慮將比較大的域放到solr外面來存儲(chǔ)。如果你覺得這樣做會(huì)有些別扭的話，可以考慮使用壓縮的域，但是這樣會(huì)加重cpu在存儲(chǔ)和讀取域的時(shí)候的負(fù)擔(dān)。不過這樣卻是可以較少i/0的負(fù)擔(dān)。

如果，你并不是總是使用 stored fields 的話，可以使用stored field的延遲加載，這樣可以節(jié)省很多的性能，尤其是使用compressed field 的時(shí)候。

Configuration Considerations

mergeFactor

這個(gè)是合并因子，這個(gè)參數(shù)大概決定了segment(索引段)的數(shù)量。

合并因子這個(gè)值告訴lucene，在什么時(shí)候，要將幾個(gè)segment合并成為一個(gè)segment, 合并因子就像是一個(gè)數(shù)字系統(tǒng)的基數(shù)一樣。

比如說，如果你將合并因子設(shè)成10，那么每往索引中添加1000個(gè)文檔的時(shí)候，就會(huì)創(chuàng)建一個(gè)新的索引段。當(dāng)?shù)?0個(gè)大小為1000的索引段添加進(jìn)來的時(shí)候，這十個(gè)索引段就會(huì)被合并成一個(gè)大小為10，000的索引段。當(dāng)十個(gè)大小為10，000的索引段生成的時(shí)候，它們就會(huì)被合并成一個(gè)大小為100，000 的索引段。如此類推下去。

這個(gè)值可以在 solrconfig.xml 中的 *mainIndex*中設(shè)置。（不用管indexDefaults中設(shè)置）

mergeFactor Tradeoffs

較高的合并因子

• 會(huì)提高索引速度
• 較低頻率的合并，會(huì)導(dǎo)致 更多的索引文件，這會(huì)降低索引的搜索效率

較低的合并因子

• 較少數(shù)量的索引文件，能加快索引的搜索速度。
• 較高頻率的合并，會(huì)降低索引的速度。

Cache autoWarm Count Considerations

當(dāng)一個(gè)新的 searcher 打開的時(shí)候，它緩存可以被預(yù)熱，或者說使用從舊的searcher的緩存的數(shù)據(jù)來“自動(dòng)加熱”。autowarmCount是這樣的一個(gè)參數(shù)，它表示從舊緩存中拷貝到新緩存中的對(duì)象數(shù)量。autowarmCount這個(gè)參數(shù)將會(huì)影響“自動(dòng)預(yù)熱”的時(shí)間。有些時(shí)候，我們需要一些折中的考慮，seacher啟動(dòng)的時(shí)間和緩存加熱的程度。當(dāng)然啦，緩存加熱的程度越好，使用的時(shí)間就會(huì)越長，但往往，我們并不希望過長的seacher啟動(dòng)時(shí)間。這個(gè)autowarm 參數(shù)可以在solrconfig.xml文件中被設(shè)置。

詳細(xì)的配置可以參考solr的wiki。

Cache hit rate（緩存命中率）

我們可以通過solr的admin界面來查看緩存的狀態(tài)信息。提高solr緩存的大小往往是提高性能的捷徑。當(dāng)你使用面搜索的時(shí)候，你或許可以注意一下filterCache,這個(gè)是由solr實(shí)現(xiàn)的緩存。

?

Explicit Warming of Sort Fields

如果你有許多域是基于排序的，那么你可以在"newSearcher"和"firstSearcher"event listeners中添加一些明顯需要預(yù)熱的查詢，這樣FieldCache 就會(huì)緩存這部分內(nèi)容。

Optimization Considerations

優(yōu)化索引，是我們經(jīng)常會(huì)做的事情，比如，當(dāng)我們建立好索引，然后這個(gè)索引不會(huì)再變更的情況，我們就會(huì)做一次優(yōu)化了。

但，如果你的索引經(jīng)常會(huì)改變，那么你就需要好好的考慮下面的因素的。

• 當(dāng)越來越多的索引段被加進(jìn)索引，查詢的性能就會(huì)降低， lucene對(duì)索引段的數(shù)量有一個(gè)上限的限制，當(dāng)超過這個(gè)限制的時(shí)候，索引段可以自動(dòng)合并成為一個(gè)。
• 在同樣沒有緩存的情況下，一個(gè)沒有經(jīng)過優(yōu)化的索引的性能會(huì)比經(jīng)過優(yōu)化的索引的性能少10%……
• 自動(dòng)加熱的時(shí)間將會(huì)變長，因?yàn)樗蕾囉谒阉鳌?/li>
• 優(yōu)化將會(huì)對(duì)索引的分發(fā)產(chǎn)生影響。
• 在優(yōu)化期間，文件的大小將會(huì)是索引的兩倍，不過最終將會(huì)回到它原來的大小，或者會(huì)更小一點(diǎn)。

優(yōu)化，會(huì)將所有的索引段合并成為一個(gè)索引段，所以，優(yōu)化這個(gè)操作其實(shí)可以幫助避免“too many files”這個(gè)問題，這個(gè)錯(cuò)誤是由文件系統(tǒng)拋出的。

Updates and Commit Frequency Tradeoffs

如果從機(jī)太經(jīng)常從主機(jī)更新的話，從機(jī)的性能是會(huì)受到影響的。為了避免，由于這個(gè)問題而引起的性能下降，我們還必須了解從機(jī)是怎樣執(zhí)行更新的，這樣我們才能更準(zhǔn)確去調(diào)節(jié)一些相關(guān)的參數(shù)（commit的頻率，spappullers,autowarming/autocount）,這樣，從機(jī)的更新才不會(huì)太頻繁。

執(zhí)行commit操作會(huì)讓solr新生成一個(gè)snapshot。如果將postCommit參數(shù)設(shè)成true的話，optimization也會(huì)執(zhí)行snapShot.

slave上的Snappuller程序一般是在crontab上面執(zhí)行的，它會(huì)去master詢問，有沒有新版的snapshot。一旦發(fā)現(xiàn)新的版本，slave就會(huì)把它下載下來，然后snapinstall.

每次當(dāng)一個(gè)新的searcher被open的時(shí)候，會(huì)有一個(gè)緩存預(yù)熱的過程，預(yù)熱之后，新的索引才會(huì)交付使用。

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

• number/frequency of snapshots ----snapshot的頻率。
• snappullers 是? 在crontab中的，它當(dāng)然可以每秒一次、每天一次、或者其他的時(shí)間間隔一次運(yùn)行。它運(yùn)行的時(shí)候，只會(huì)下載slave上沒有的，并且最新的版本。
• Cache autowarming 可以在solrconfig.xml文件中配置。

如果，你想要的效果是頻繁的更新slave上的索引，以便這樣看起來比較像“實(shí)時(shí)索引”。那么，你就需要讓snapshot盡可能頻繁的運(yùn)行，然后也讓 snappuller頻繁的運(yùn)行。這樣，我們或許可以每5分鐘更新一次，并且還能取得不錯(cuò)的性能，當(dāng)然啦，cach的命中率是很重要的，恩，緩存的加熱時(shí)間也將會(huì)影響到更新的頻繁度。

cache對(duì)性能是很重要的。一方面，新的緩存必須擁有足夠的緩存量，這樣接下來的的查詢才能夠從緩存中受益。另一方面，緩存的預(yù)熱將可能占用很長一段時(shí)間，尤其是，它其實(shí)是只使用一個(gè)線程，和一個(gè)cpu在工作。snapinstaller太頻繁的話，solr slave將會(huì)處于一個(gè)不太理想的狀態(tài)，可能它還在預(yù)熱一個(gè)新的緩存，然而一個(gè)更新的searcher被opern了。

怎么解決這樣的一個(gè)問題呢，我們可能會(huì)取消第一個(gè)seacher，然后去處理一個(gè)更新seacher，也即是第二個(gè)。然而有可能第二個(gè)seacher 還沒有被使用上的時(shí)候，第三個(gè)又過來了?？窗?#xff0c;一個(gè)惡性的循環(huán)，不是。當(dāng)然也有可能，我們剛剛預(yù)熱好的時(shí)候就開始新一輪的緩存預(yù)熱，其實(shí)，這樣緩存的作用壓根就沒有能體現(xiàn)出來。出現(xiàn)這種情況的時(shí)候，降低snapshot的頻率才是硬道理。

Query Response Compression

在有些情況下，我們可以考慮將solr xml response 壓縮后才輸出。如果response非常大，就會(huì)觸及NIc i/o限制。

當(dāng)然壓縮這個(gè)操作將會(huì)增加cpu的負(fù)擔(dān)，其實(shí)，solr一個(gè)典型的依賴于cpu處理速度的服務(wù)，增加這個(gè)壓縮的操作，將無疑會(huì)降低查詢性能。但是，壓縮后的數(shù)據(jù)將會(huì)是壓縮前的數(shù)據(jù)的6分之一的大小。然而solr的查詢性能也會(huì)有15%左右的消耗。

至于怎樣配置這個(gè)功能，要看你使用的什么服務(wù)器而定，可以查閱相關(guān)的文檔。

Embedded vs HTTP Post

使用embeded 來建立索引，將會(huì)比使用xml格式來建立索引快50%。

RAM Usage Considerations（內(nèi)存方面的考慮）

OutOfMemoryErrors

如果你的solr實(shí)例沒有被指定足夠多的內(nèi)存的話，java virtual machine也許會(huì)拋outof memoryError，這個(gè)并不對(duì)索引數(shù)據(jù)產(chǎn)生影響。但是這個(gè)時(shí)候，任何的 adds/deletes/commits操作都是不能夠成功的。

Memory allocated to the Java VM

最簡單的解決這個(gè)方法就是，當(dāng)然前提是java virtual machine 還沒有使用掉你全部的內(nèi)存，增加運(yùn)行solr的java虛擬機(jī)的內(nèi)存。

Factors affecting memory usage（影響內(nèi)存使用量的因素）

我想，你或許也會(huì)考慮怎樣去減少solr的內(nèi)存使用量。

其中的一個(gè)因素就是input document的大小。

當(dāng)我們使用xml執(zhí)行add操作的時(shí)候，就會(huì)有兩個(gè)限制。

• document中的field都是會(huì)被存進(jìn)內(nèi)存的，field有個(gè)屬性叫maxFieldLength，它或許能幫上忙。
• 每增加一個(gè)域，也是會(huì)增加內(nèi)存的使用的。

轉(zhuǎn)載于:https://www.cnblogs.com/SuperBing/archive/2013/01/30/2882801.html

總結(jié)

以上是生活随笔為你收集整理的olr 性能调优 NO_NORMS的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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