es負載不均 - Elasticsearch

導致Elasticsearch（簡稱ES）的負載不均問題的原因很多，目前主要包括shard設定不合理、segment大小不均、冷熱資料需求、負載平衡及多可用性區域架構部署的長串連不釋放等。本文介紹ES叢集負載不均問題的分析方法及解決方案。

問題現象

節點間磁碟使用率差距不大，監控中節點CPU使用率或load_1m呈現明顯的負載不均衡現象。
節點間磁碟使用率差距很大，監控中節點CPU使用率或load_1m呈現明顯的負載不均衡現象。

問題原因

Shard設定不合理。
重要
大多數負載不均問題是由於shard設定不合理導致，建議優先排查。
Segment大小不均。
存在典型的冷熱資料需求情境。
重要
冷熱資料情境（例如查詢中添加了routing、查詢頻率較高的熱點資料）必然導致資料出現負載不均。
採用負載平衡及多可用性區域架構部署時，由於長串連不釋放可能會導致流量不均（很少出現），詳情請參見長串連不均勻。

重要

其他情況導致的負載不均問題，請聯絡阿里雲支援人員工程師排查。

Shard設定不合理

情境
A公司有一個阿里雲ES執行個體，該執行個體配置為：3個主節點16核32GB、9個資料節點32核64GB，主要資料儲存在test索引上。當在業務高峰期的時候（16:21~18:00左右），查詢QPS為2000左右（查詢中沒有冷熱資料分離）、寫入QPS為1000、2個節點的CPU達到100，負載過高影響ES服務。
分析
1. 優先檢查查詢期間的網路及ECS情況。如果ECS環境正常，再查看網路流量監控。
  根據監控結果發現異常期間（16:21）網路請求上升，查詢QPS上升，對應的CPU節點負載大幅增高。結合查詢策略，初步判斷負載高的節點主要承擔了查詢請求。
2. 使用GET _cat/shards?v，查看索引的shard資訊。
  從結果可以看到test索引的shard在負載高的節點上呈現的數量較多，說明shard分配不均；然後查看磁碟使用率監控圖，顯示負載高的節點使用率比其他節點高。由此可以得出，shard分配不均衡導致儲存不均，在業務查詢或寫入中，儲存高的節點承擔主要的查詢和寫入。
3. 使用GET _cat/indices?v，查看索引資訊。
  從結果可以看到索引的主shard數量為5，副shard數量為1。結合叢集配置，發現存在節點shard分配不均的現象，其次叢集中存在被刪除的文檔。ES在檢索過程中也會檢索.del檔案，然後過濾標記有.del的文檔，大大地降低檢索效率，耗費規格資源，建議在業務低峰期進行force merge。
4. 查看主日誌及searching慢日誌。
  從結果可以看到查詢請求都是普通的term查詢，且主日誌正常，可以排除ES叢集本身出現問題以及存在消耗CPU的查詢語句的情況。
總結
通過以上分析，可以判斷CPU負載不均主要是由於shard分布不均導致的。重新分配分區，確保主shard數與副shard數之和是叢集資料節點的整數倍，叢集的CPU負載趨於穩定。最佳化後的CPU趨勢圖如下。
解決方案
在建立索引時，合理規劃shard，詳情請參見Shard評估建議。

Shard評估建議

Shard大小和數量是影響ES叢集穩定性和效能的重要因素之一。ES叢集中任何一個索引都需要有一個合理的shard規劃。合理的shard規劃能夠防止因業務不明確，導致分區龐大消耗ES本身效能的問題。

說明

ES 7.x以下版本的索引預設包含5個主shard，1個副shard；ES 7.x 及以上版本的索引預設包含1個主shard，1個副shard。

建議在小規格節點下，單個shard大小不要超過30GB。對於更高規格的節點，單個shard大小不要超過50GB。
對於日誌分析或者超大索引情境，建議單個shard大小不要超過100GB。
建議shard的個數（包括副本）要儘可能等於資料節點數，或者是資料節點數的整數倍。
說明
主分區不是越多越好，因為主分區越多，ES效能開銷也會越大。
建議單節點shard總數按照單節點記憶體*30進行評估，如果shard數量太多，極易引起檔案控制代碼耗盡，導致叢集故障。
建議單個節點上同一索引的shard個數不要超5個。
如果您使用了自動建立索引功能，可通過設定情境模板，調整索引shard均衡，詳情請參見修改情境化配置模板。

Segment大小不均

情境
A公司ES叢集忽然出現單個節點CPU飆升，影響查詢效能。查詢主要集中在test索引、shard設定為3主1副、shard分配均衡、索引中存在大量的delete.doc，且優先排除了底層主機問題。
分析
1. 在查詢body中添加"profile": true。
  根據結果可以看到test索引的1號shard查詢時間比其他shard長。
2. 查詢中分別指定preference=_primary和preference=_replica，body中添加"profile": true，分別查看主副shard查詢消耗的時間。
  根據結果定位出索引的1號shard耗時主要體現在主shard上，判斷和shard有關。
3. 使用GET _cat/segments/index?v&h=shard,segment,size,size.memory,ip及GET _cat/shards?v，查看索引的1號shard的資訊。
  從結果可以看到索引的1號shard中存在比較大的segment，且doc數量比正常的副shard多。由此可以判斷負載不均與segment大小不均有關。
  說明
  造成主副shard的doc數量不一致的原因有很多，例如以下兩種情況：
  如果一直有doc寫入shard，由於主副資料同步有一定延遲，會導致資料不一致。但一般停止寫入後，主副doc數量是一致的。
  如果使用自動產生docid的方式寫入doc，由於主shard寫入完成後會轉寄請求到副shard，因此在此期間，如果執行了刪除操作，例如並行發送Delete by Query請求刪除了主分區上剛寫完的doc，那麼副shard也會執行此刪除請求；然後主shard又轉寄寫入請求到副shard上，對於自動產生的id，doc將直接寫入副shard，不進行檢查，最終導致主副shard的doc數量不一致，同時在doc.delete中也可以看到主shard中存在大量的刪除文檔。
解決方案（任選一種）
- 在業務低峰期進行force merge，將緩衝中的delete.doc徹底刪除，將小segment合并成大segment。
- 重啟主shard所在節點，觸發副shard升級為主shard。並且重建副shard，副shard複製新的主shard中的資料，保持主副shard的segment一致。
最佳化後的負載監控圖如下。

長串連不均勻

情境
A公司為實現ES叢集跨地區容災部署，分別在b區和c區部署高可用架構，在持續提供業務操作時，叢集中c區節點負載明顯比b區高，並且已經排除資料分配不均及硬體問題。
分析
1. 觀察近4天兩地區節點的CPU監控。
  根據結果可以看到兩地區節點CPU出現較大負載變動。
2. 觀察節點TCP串連。
  根據結果可以看到兩個地區下的串連數相差很大。判定與網路不均相關。
3. 排查用戶端的串連情況。
  用戶端使用長串連，建立串連比較少，恰恰命中了多可用性區域網路獨立調度的風險（網路服務是基於串連數獨立調度的，每個調度單元會選擇自己認為最優的節點進行建立，獨立調度的效能會更高，但獨立調度的風險是當新串連比較少的時候，有一定機率出現大部分調度單元都選擇相同的節點去建立串連）。ES的協調節點對於請求的轉寄是同地區優先，即ES將請求轉到其他地區的可能性較小，這樣就導致目前範圍出現負載不均的問題。
解決方案（任選一種）
- 用戶端配置httpClientBuilder.setConnectionTimeToLive()。例如，配置串連有效時間長度為5分鐘：httpClientBuilder.setConnectionTimeToLive(5, TimeUnit.MINUTES)。詳細資料，請參見HttpAsyncClientBuilder。
  說明
  用戶端配置連結有效時間長度需要使用ES推薦的httpClientBuilder.setConnectionTimeToLive()，配置別的參數效果可能不太明顯，例如：httpClientBuilder.setKeepAliveStrategy()。
- 並發重啟用戶端，重建立立串連。
- 使用單獨的協調節點，通過工作職責劃分來降低風險。使用協調節點轉寄複雜流量，即使負載高，也不會影響到後面的資料節點。
最佳化後的負載監控圖如下。

單個索引分區不均勻

情境：觀察每個節點分區較均衡，但是業務索引在負載較高的節點分布的分區數比較多或承載單分區資料量多。
解決方案：設定控制每個節點上分配給單個索引的最大分區數量index.routing.allocation.total_shards_per_node，參數取值計算公式為（主+副本數）/資料節點個數，參數值需為整數，小數向上取整。
```
PUT   index_name/_settings
{
  { "index.routing.allocation.total_shards_per_node" : "3" }
}
```