背景
ES叢集在某些情況下會出現CPU使用率高的現象，具體有兩種表現：
1. 個別節點CPU使用率遠高於其他節點；
2. 叢集中所有節點CPU使用率都很高。
下面我們來詳細分析這兩種可能出現的情況。
一、出現叢集負載不均的問題如何解決？
問題現象
叢集在某些情況下會個別節點CPU使用率遠高於其他節點的現象，具體表現為： ES叢集UI控制檯節點監控上可以明顯看到某些節點CPU使用率很高。
原因
可能存在以下幾種原因：
索引分片設計不合理
Segment大小不均
存在典型的冷熱資料需求場景
問題分析及解決方案
原因一：Shard設定不合理
1。 登入Kibana控制檯，在開發工具中執行以下命令，檢視索引的shard資訊，確認索引的shard在負載高的節點上呈現的數量較多，說明shard分配不均；
GET _cat/shards？v
2。 登入Kibana控制檯，在開發工具中執行以下命令，檢視索引資訊。結合叢集配置，確認存在節點shard分配不均的現象；
GET _cat/indices？v
解決方案
重新分配分片，合理規劃shard，確保主shard數與副shard數之和是叢集資料節點的整數倍；
由於Shard大小和數量是影響Elasticsearch叢集穩定性和效能的重要因素之一。Elasticsearch叢集中任何一個索引都需要有一個合理的shard規劃。合理的shard規劃能夠防止因業務不明確，導致分片龐大消耗Elasticsearch本身效能的問題。以下是shard規劃時的幾個建議：
儘量遵循索引單分片20g~50g的設計原則；
索引儘量增加時間字尾，按時間滾動，方便管理；
在遵循單分片設計原則的前提下，預測出索引最終大小，並根據叢集節點數設計索引分片數量，使分片儘量平均分佈在各個節點。
特別注意
主分片不是越多越好，因為主分片越多，Elasticsearch效能開銷也會越大。建議單節點shard總數按照單節點記憶體*30進行評估，如果shard數量太多，極易引起檔案控制代碼耗盡，導致叢集故障。
Elasticsearch在檢索過程中也會檢索
。del
檔案，然後過濾標記有
。del
的文件，這會降低檢索效率，耗費規格資源，建議在業務低峰期進行強制合併操作，具體請參見force merge。
原因二：Segment大小不均
在查詢body中新增
“profile”： true
，檢查test索引是否存在某個shard查詢時間比其他shard長。
查詢中分別指定
preference=_primary
和
preference=_replica
，在body中新增
“profile”： true
，分別檢視主副shard查詢消耗的時間。檢查較耗時的shard主要體現在主shard上還是副shard上。
登入Kibana控制檯，在開發工具中執行以下命令，檢視shard，並根據其中segment資訊分析問題所在，確認負載不均與segment大小不均有關。
GET _cat/segments/index？v&h=shard，segment，size，size。momery，ipGET _cat/shards？v
解決方案
參考以下兩種方法其中一種解決問題：
在業務低峰期進行強制合併操作，具體請參見force merge，將快取中的delete。doc徹底刪除，將小segment合併成大segment。
重啟主shard所在節點，觸發副shard升級為主shard。並且重新生成副shard，副shard複製新的主shard中的資料，保持主副shard的segment一致。
原因三：存在典型的冷熱資料需求場景
如果查詢中添加了routing或查詢頻率較高的熱點資料，則必然導致資料出現負載不均。
二、出現ES叢集整體CPU使用率都很高時該如何排查？
問題現象
叢集所有節點CPU都很高，但讀寫都不是很高。
具體表現可以從kibana端Stack Monitoring監控頁面看到：
原因
出現這種情況，由於表面上看叢集讀寫都不高，導致很難快速從監控上找到根因。所以需要細心觀察，從細節中找答案，下面我們介紹幾種可能出現的場景以及排查思路。
問題分析及解決方案
原因一：比較大的查詢請求導致CPU飆高
這種情況比較常見，細心一點的話可以從監控上找到線索：
從監控上可以發現，查詢請求量的波動與叢集最大CPU使用率是基本吻合的。 發現了問題所在，進一步確認則需要開啟叢集的慢日誌收集，可以參考官方文件：叢集日誌說明。從慢日誌中，我們可以得到更多資訊。比如引起慢查詢的索引、查詢引數以及內容。
解決方案
針對這種情況，我們一般建議： 1、儘量避免大段文字搜尋，最佳化查詢； 2、透過慢日誌確認查詢慢的索引，對於一些資料量不大的索引，設定少量分片多副本，比如1分片多副本，以此來提高查詢效能。
原因二：寫入請求導致CPU飆高
同理，首先透過監控來觀察到CPU飆高是與寫入相關，然後開啟叢集的慢日誌收集，確認寫入慢的請求，進行最佳化。也可以透過獲取
hot_threads
資訊來確認什麼執行緒在消耗CPU：
curl http：//9。15。49。78：9200/_nodes/hot_threads
比如這裡發現的是有大量ingest pipeline操作，ingest操作是十分消耗資源的。
解決方案
如遇到上面這種問題，則需要業務方根據實際情況來最佳化。
小結
排查該類問題的關鍵點，還是在於善用叢集的監控指標來快速判斷問題的方向，再配合叢集日誌來定位問題的根因，才能快速地解決問題。
