在 Elasticsearch 中有一些熱點，人們可能不可避免的會碰到。 我們理解的，所有的調整就是為了優化，但是這些調整，你真的不需要理會它。因為它們經常會被亂用，從而造成系統的不穩定或者糟糕的效能，甚至兩者都有可能。

垃圾回收器編輯

        這裡已經簡要介紹了 垃圾回收入門，JVM 使用一個垃圾回收器來釋放不再使用的記憶體。 這篇內容的確是上一篇的一個延續， 但是因為重要，所以值得單獨拿出來作為一節。

       不要更改預設的垃圾回收器！

       Elasticsearch 預設的垃圾回收器（ GC ）是 CMS。 這個垃圾回收器可以和應用並行處理，以便它可以最小化停頓。 然而，它有兩個 stop-the-world 階段，處理大記憶體也有點吃力。

       儘管有這些缺點，它還是目前對於像 Elasticsearch 這樣低延遲需求軟體的最佳垃圾回收器。官方建議使用 CMS。

        現在有一款新的垃圾回收器，叫 G1 垃圾回收器（ G1GC ）。 這款新的 GC 被設計，旨在比 CMS 更小的暫停時間，以及對大記憶體的處理能力。 它的原理是把記憶體分成許多區域，並且預測哪些區域最有可能需要回收記憶體。通過優先收集這些區域（ garbage first

       聽起來很棒！遺憾的是，G1GC 還是太新了，經常發現新的 bugs。這些錯誤通常是段（ segfault ）型別，便造成硬碟的崩潰。 Lucene 的測試套件對垃圾回收演算法要求嚴格，看起來這些缺陷 G1GC 並沒有很好地解決。

        我們很希望在將來某一天推薦使用 G1GC，但是對於現在，它還不能足夠穩定的滿足 Elasticsearch 和 Lucene 的要求。

執行緒池編輯

        許多人 喜歡

       Elasticsearch 預設的執行緒設定已經是很合理的了。對於所有的執行緒池（除了 搜尋 ），執行緒個數是根據 CPU 核心數設定的。 如果你有 8 個核，你可以同時執行的只有 8 個執行緒，只分配 8 個執行緒給任何特定的執行緒池是有道理的。

       搜尋執行緒池設定的大一點，配置為 int（（ 核心數 ＊ 3 ）／ 2 ）＋ 1 。

      你可能會認為某些執行緒可能會阻塞（如磁碟上的 I／O 操作），所以你才想加大執行緒的。對於 Elasticsearch 來說這並不是一個問題：因為大多數 I／O 的操作是由 Lucene 執行緒管理的，而不是 Elasticsearch。

        此外，執行緒池通過傳遞彼此之間的工作配合。你不必再因為它正在等待磁碟寫操作而擔心網路執行緒阻塞， 因為網路執行緒早已把這個工作交給另外的執行緒池，並且網路進行了響應。

       最後，你的處理器的計算能力是有限的，擁有更多的執行緒會導致你的處理器頻繁切換執行緒上下文。 一個處理器同時只能執行一個執行緒。所以當它需要切換到其它不同的執行緒的時候，它會儲存當前的狀態（暫存器等等），然後載入另外一個執行緒。 如果幸運的話，這個切換髮生在同一個核心，如果不幸的話，這個切換可能發生在不同的核心，這就需要在核心間總線上進行傳輸。

       這個上下文的切換，會給 CPU 時鐘週期帶來管理排程的開銷；在現代的 CPUs 上，開銷估計高達 30 μs。也就是說執行緒會被堵塞超過 30 μs，如果這個時間用於執行緒的執行，極有可能早就結束了。

       人們經常稀裡糊塗的設定執行緒池的值。8 個核的 CPU，我們遇到過有人配了 60、100 甚至 1000 個執行緒。 這些設定只會讓 CPU 實際工作效率更低。

       所以，下次請不要調整執行緒池的執行緒數。如果你真 想調整 ， 一定要關注你的 CPU 核心數，最多設定成核心數的兩倍，再多了都是浪費。

轉自：https://www.elastic.co/guide/cn/elasticsearch/guide/current/dont-touch-these-settings.html