收到es的告警，在1小時內意外分配了碎片，從而導致集群狀態 green > yellow > red > yellow > green 頻繁切換？在此期間，es不可訪問，並且呼叫api開始返回非200的狀態碼。
環境
3個主節點和3個工作節點。
這種鋸尺模式的原因是，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
我觀察到garbage collector每隔1分鐘執行一次，這是由於elasticsearch自己的程式（例如對分片的搜尋查詢）導致物件分配率很高，而3個worker節點上的許多分片會導致很多物件高頻。同樣，執行garage collector時，也會導致「 stop the world state」（停止世界狀態）意味著主彈性搜尋工作人員的主線程停止。當彈性搜尋的主線程長時間不響應時，elasticsearch主節點將假定工作節點已離開群集，並在其他節點之間重新分配分片。
以下是從elasticsearch日誌中獲得的示例錯誤：
以前，我為每個索引設定「 2個具有6個副本的主節點」，這會導致大量分片，而更多的分片意味著對每個分片進行更多的並行讀取操作，從而導致頻繁建立更多的物件。elasticsearch建議每個節點有600個分片。
因此，我決定進行以下更改：
增加工作節點的原因
首先，隨著工作節點數量的增加，我們能夠在每個節點上保持最小的碎片數。
其次，以前（在每個工作節點上）有3個並行的垃圾收集器不得不處理大量垃圾收集，但是對於5個垃圾收集器，垃圾收集的任務被劃分了。
第三，將碎片劃分為5個節點，通過搜尋查詢建立的物件也將劃分為5個節點。因此，在每個節點上，頻繁的物件計數減少，從而減少了垃圾收集器執行的頻率。
某次gc頻繁
使用jmap dump得到檔案，mat分析，大量finalizer物件佔據了主要空間。finalizer物件是實現了finalize 方法的f類，生成例項時一對一生成後，掛在finalizer類的靜態佇列 乙個gcroot 下的。它可以保證在一次gc後，如果finalizer物件對應的f類只有fin...
頻繁序列模式挖掘
序列模式是頻繁模式的一種特殊情況，它們的應用範圍完全不一樣！如 購買物品 尿布 啤酒 可樂 麵包 尿布 啤酒 上述購物清單是兩個使用者的購物清單，根據上面的清單，我們可以發現尿布和啤酒組合起來一起購買的情況較多，因此超市可以根據這樣的頻繁項集分析，將尿布和啤酒放在較近的地方，或者將尿布和啤酒同時 等...
頻繁出現的數值
題目大意 給乙個非降序排列的整數陣列a，你的任務是對於一系列詢問 i,j 回答ai,ai 1.aj中次數出現最多的值所出現的次數。分析 由於數列是非降序的，所以所有相等的數都會聚集在一起。這樣我們就可以把整個陣列進行編碼。如 1,1,1,2,2,2,4就可以編碼成 1,1 1,2 2,3 4,1 表...