轉自：http://rdc.taobao.com/team/jm/archives/1753
共整理三部分，第一部分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）,這樣，從機的更新才不會太頻繁。
執行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的頻率才是硬道理。
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的對應處理。