Elasticsearch重要文章之一:不要觸碰這些配置

在Elasticsearch中有一些熱點，人們可能不可避免的會碰到。咱們所理解的，全部的調整就是爲了優化，可是這些調整，你真的不須要理會它。由於它們常常會被亂用，從而形成系統的不穩定或者糟糕的性能，甚至二者都有可能。

垃圾收集器

在章節已經有一個簡短的介紹，JVM使用一個垃圾收集器來釋放再也不使用的內存，這篇內容的確是上一篇的一個延續，可是由於重要，因此值得單獨拿出來做爲一節。

不要更換默認的垃圾收集器！
Elasticsearch默認的垃圾收集器是CMS垃圾收集器。這個垃圾收集器由於能夠和應用並行處理，因此有很小的暫停，固然它有兩個stop-the-world階段，處理大內存也有點吃力。

儘管這些缺點，它也是目前像Elasticsearch這樣低延遲需求的軟件的最佳垃圾收集器。官方建議使用CMS。

如今有一款新的垃圾收集器，叫G1垃圾收集器，這款GC設計目的是比CMS更小的暫停時間，以及對大內存的處理能力。它的原理是把內存分紅許多區域，而且預測哪些區域最有可能須要回收內存。G1 GC經過首先收集這些區域，產生更小的暫停時間，從而能應對更大的內存。

聽起來不錯，很遺憾的是G1 GC仍是太新，常常有bug爆出，這些bug大都是段錯誤那種，會致使硬盤崩潰。Lucene的測試套件對GC是很嚴格殘酷的，好像G1 GC一直都沒法徹底勝任。

咱們很但願在未來某一天推薦使用G1 GC，可是對於如今，它還不能足夠穩定以知足Elasticsearch和luncene的要求。

線程池

許多人喜歡調整線程池，不管什麼緣由，人們好像都沒法抵擋的想增長線程數。索引太多了？增長線程！搜索太多了，增長線程！節點空閒率低於95%？ 增長線程！
Elasticsearch默認的線程設置已是很合理的了。對於全部的線程池（除了搜索的），線程個數是根據CPU核心數設置的。若是你有8個核，你能夠同時運行8個線程，那麼對於一些線程池，你設置8個線程是合適的。

搜索線程池設置的大一點，是核心數的3倍。

你可能爭辯說，一些線程會堵塞在IO處，因此你纔想加大線程的。對於elasticsearch來講，這不是問題，由於大多數IO的操做是由Lucene線程管理的，而不是Elasticsearch。
此外，線程池經過彼此之間的合做工做。你不須要擔憂網絡相關的線程由於它在等待磁盤寫入而堵塞。由於網絡線程早已把這個工做交給另外的線程池，而且網絡進行了響應。

最後，你的處理器的計算容量是有限的，擁有更多的線程會致使你的處理器頻繁切換線程上下文。一個處理器同時只能運行一個線程，因此當它須要切換到其它不一樣的線程的時候，它會存儲當前的狀態（寄存器等等），而後加載另一個線程。若是幸運的話，這個切換髮生在同一個cpu核心，若是不幸的話，這個切換可能發生在不一樣的核心，這就須要在內核間總線上進行傳輸。

這個上下文的切換，會循環的帶來管理調度開銷，在現代的CPU上，估計高達30us，也就是說線程會被堵塞30us，若是這個時間用於線程的運行，估計早就結束了。

人們常常稀裏糊塗的設置線程池的值，8個核的CUP，咱們見過有人配了60,100甚至1000個線程，這些設置只會讓CPU實際工做效率更低。

因此下次請不要調整線程池的線程數，若是真想調整，必定要關注你的CPU核心數，最多設置成核心數的兩倍，再多了都是浪費。