收到ES的告警，在1小時內意外分配了碎片，從而導致叢集狀態 Green > Yellow > Red > Yellow > Green 頻繁切換？在此期間，ES不可訪問，並且呼叫API開始返回非200的狀態碼。

環境

3個主節點和3個工作節點。

錯誤分析GC鋸尺圖

這種鋸尺模式的原因是，ELasticsearch在執行某些操作搜尋查詢，寫入查詢，重新整理，重新整理操作等，頻繁的建立新物件，JVM需要不斷往堆上分配記憶體，但是，這些物件大多數都比較短暫，很快就會被堆的young區域中的GC收集。GC完成後，在記憶體使用圖表中看到它下降。

注意：大多數Elasticsearch物件都是短暫的，並且由Young區域的GC收集。

物件的高分配率導致效能問題

GC日誌提供了一種捕獲應用程式分配物件頻率的方法。雖然高分配率不一定是問題，但它們可能導致效能問題。要檢視這是否影響應用，可以比較收集之後和下一個收集之前的young 一代的大小。

例如，以下三條GC日誌顯示該應用程式正在以約12.48GB /秒的速度分配物件。

[31.087s][info ][gc ] GC(153) Pause Young (Normal) (G1 Evacuation Pause) 3105M->794M(3946M) 55.590ms[31.268s][info ][gc ] GC(154) Pause Young (Normal) (G1 Evacuation Pause) 3108M->798M(3946M) 55.425ms [31.453s][info ][gc ] GC(155) Pause Young (Normal) (G1 Evacuation Pause) 3113M->802M(3946M) 55.571ms

在31.087和31.268之間分配了2314M（3108M-794M），在31.268和31.453之間分配了另外2315M（3113M-798M）。每200毫秒或12.48GB /秒大約可消耗2.3GB。根據應用程式的行為，以該速率分配物件可能會對其效能產生負面影響。

物件的高分配導致頻繁收集

我觀察到Garbage Collector每隔1分鐘執行一次，這是由於Elasticsearch自己的程式（例如對分片的搜尋查詢）導致物件分配率很高，而3個worker節點上的許多分片會導致很多物件高頻。同樣，執行Garage Collector時，也會導致“ Stop the World State”（停止世界狀態）意味著主彈性搜尋工作人員的主執行緒停止。當彈性搜尋的主執行緒長時間不響應時，elasticsearch主節點將假定工作節點已離開群集，並在其他節點之間重新分配分片。

以下是從Elasticsearch日誌中獲得的示例錯誤：

解決方案

以前，我為每個索引設定“ 2個具有6個副本的主節點”，這會導致大量分片，而更多的分片意味著對每個分片進行更多的並行讀取操作，從而導致頻繁建立更多的物件。Elasticsearch建議每個節點有600個分片。

因此，我決定進行以下更改：

2主節點和1個副本work節點從3增加到5增加工作節點的原因

首先，隨著工作節點數量的增加，我們能夠在每個節點上保持最小的碎片數。

其次，以前（在每個工作節點上）有3個並行的垃圾收集器不得不處理大量垃圾收集，但是對於5個垃圾收集器，垃圾收集的任務被劃分了。

第三，將碎片劃分為5個節點，透過搜尋查詢建立的物件也將劃分為5個節點。因此，在每個節點上，頻繁的物件計數減少，從而減少了垃圾收集器執行的頻率。