Elasticsearch 集群典型報錯日志"逆向"分析

作者：銘毅天下 2024-08-06 09:54:20

開發前端

通過合理配置和優化，Elasticsearch 集群的性能問題是可以逐步解決的。但，爆改集群默認配置是不建議的。關鍵在于合理分配資源，優化查詢和索引操作，同時結合監控工具和日志分析，及時發現并解決潛在問題。

1、集群環境及存在問題

1.1 集群環境

1 臺宿主機，2 個 ES 節點。
宿主機配置：56 核 CPU， 256G 內存，普通非SSD 磁盤
宿主機除了部署 ES 集群兩個節點，還部署了其他服務如 redis、其他（不詳）。

1.2 索引分片

單索引 700 GB 左右。
20 個分片。

1.3 改動過如下配置

圖片

1.4 存在問題

Elasticsearch 查詢特別慢，內存使用率 93%, 現在沒什么解決思路。

————問題來自球友：https://t.zsxq.com/LcRV0

2、僅如上信息，可以發現的問題

2.1 存在典型問題

兩節點分布在一臺機器，還有混部了一些其他的服務。

本質是兩虛擬機共享一個實體服務器。

混合部署了 Redis 等服務，這是大問題。

Redis 屬于內存數據庫，“吃內存”厲害。我們一般不建議這么搞，官方也不建議這么搞。

2.2 盲目修改集群配置，可能帶來潛在風險

其中，search.max_buckets 默認值：10000。現在擴大了1000倍，改成了 1000 萬。

該配置項用于限制 Elasticsearch 中聚合查詢（如 histogram 聚合）中返回的最大桶數。過高的桶數可能會導致內存使用過多，影響集群性能。

其中，thread_pool.write.queue_size 默認值：200。現在改成 2048，擴大了 10 倍+。

該配置項用于指定寫入操作的線程池隊列大小，當隊列滿時，新的寫入請求將被拒絕。

增大隊列大小可以緩解寫入壓力，但也會增加內存消耗。其中，indices.fielddata.cache.size 默認值：未設置具體默認值（動態分配），

該配置項用于限制字段數據緩存的大小，默認情況下是根據 JVM 堆內存動態調整。可以使用百分比表示，例如 20% 表示使用最大可用堆內存的 20% 作為緩存。

也就是這個支持動態調整的，咱們給寫死了。

上述修改其實都經不起推敲和驗證，非常的“大膽”，但出問題往往也會超出咱們的預期。

2.2 其他問題不明顯

疑似問題1：單索引是700g左右，分片20？單分片大小35g，具體單文檔細節不詳。
疑似問題2：只有2臺機器。本質兩臺機器角色都具備：主節點、數據節點角色，其中一臺還充當協調節點角色。
疑似問題3：癥狀提及的查詢慢問題，需要給出慢查詢日志，需要給出監控指標數據，需要描述一下業務，需要給出檢索的DSL語句。

3、拿到集群日志，一切變得明朗

圖片

如上截圖為兩個節點的日志，-02-1 為主節點日志，-02-2 為另外一個節點的日志。

4、主節點日志“逆向”分析

4.1 test-1016-2024-08-02-1.log 日志含拒絕請求“9790”次

從最早日期：[2024-08-02T17:15:54,487

到最晚日期：[2024-08-02T17:28:57,460]

累計時長：13 分 2.973 秒。

共有如下類似相同報錯：9790 次。

日志截取如下：

Caused by: org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution of org.elasticsearch.common.util.concurrent.TimedRunnable@5ccc5247 on QueueResizingEsThreadPoolExecutor[name = slav1/search, queue capacity = 1000, min queue capacity = 1000, max queue capacity = 1000, frame size = 2000, targeted response rate = 1s, task execution EWMA = 12.2ms, adjustment amount = 50, org.elasticsearch.common.util.concurrent.QueueResizingEsThreadPoolExecutor@10c62020[Running, pool size = 85, active threads = 85, queued tasks = 1000, completed tasks = 370806]]

也就是說，當前節點已經高負荷扛不住了。

圖片

上述錯誤是由于 Elasticsearch 線程池飽和導致的。這具體表現在 EsRejectedExecutionException 中，表示有任務被拒絕執行。

詳細原因拆解如下：

QueueResizingEsThreadPoolExecutor 飽和

報錯信息顯示 search 線程池的隊列已經達到最大容量（queue capacity = 1000），并且活動線程數已經達到最大（active threads = 85），所以新任務被拒絕執行。

任務積壓

報錯信息中提到有 1000 個任務在隊列中等待執行，說明當前系統的負載很高，可能是因為查詢請求過多或請求處理時間較長。

搜索請求過多或復雜

從報錯信息看，搜索請求的參數和查詢條件比較復雜（包含多重布爾查詢、排序等，見 4.2 的 DSL 語句），這可能導致了較高的計算和處理時間。

可能的解決方案探討：

方案1：增加節點資源

增加 Elasticsearch 集群中的節點數，或者增加現有節點的資源（CPU、內存等），以分擔負載。

看老板給不給硬件投入支持。

方案2：優化查詢

簡化查詢條件，減少不必要的字段返回和高亮顯示等操作，盡量優化查詢性能。見4.2 章節分析。

方案3：調整線程池設置

調整 search 線程池的配置，如增大 queue capacity 和 pool size，以便處理更多的并發請求。

但前提：必須結合硬件資源進行合理調整，而不是盲改 100倍、1000倍甚至更大的值。

4.2 打開slow_log 慢日志后，DSL語句顯現。

Elasticsearch 日志能否把全部請求打印出來？

圖片

4.2.1 問題1："track_total_hits": 2147483647

問題描述：將 track_total_hits 設置為 2147483647（即 2^31-1）是非常高的一個值，會導致性能問題。

原因：

（1）性能消耗大。

計算所有匹配文檔的總數需要遍歷所有匹配的文檔，這對于大規模數據集來說是非常耗時和耗資源的操作。

（2）不必要的精確度。

通常用戶并不需要一個如此精確的匹配數量，大部分情況下一個較小的估算值已經足夠。

Elasticsearch 8.X 聚合查詢下的精度問題及其解決方案

推薦優化后的解決方案：

（1）合理設置 track_total_hits

將 track_total_hits 設置為 true 或者一個合理的數值，例如 10000，以滿足大多數統計需求，同時減少系統負擔。

（2）分頁處理

通過分頁獲取數據，而不是一次性獲取大量匹配文檔的總數。

干貨 | 全方位深度解讀 Elasticsearch 分頁查詢

4.2.2 問題2：基于腳本排序

問題描述：腳本排序會極大地影響查詢性能，尤其是在處理大量數據時。

原因：

（1）計算開銷大

腳本排序需要在每個匹配的文檔上執行腳本計算，這會導致高額的 CPU 開銷。

（2）緩存難以利用

腳本排序結果難以緩存，因為每次請求可能都會涉及不同的計算邏輯和參數。

推薦解決方案

（1）預計算字段

盡量將排序邏輯預計算成字段，存儲在文檔中，避免在查詢時實時計算。

例如，預先計算并存儲評分、排名等，可以借助 ingest pipeline 預處理實現。

這就是咱們之前多次強調過的“空間換時間”。

Elasticsearch的ETL利器——Ingest節點

Elasticsearch 預處理沒有奇技淫巧，請先用好這一招！

（2）優化腳本

如果必須使用腳本排序，確保腳本盡可能簡單和高效。使用 Painless 腳本語言并確保腳本已編譯優化。最好別用！

（3）索引優化

使用合適的索引結構和字段類型，確保查詢性能和排序效率。

4.2.3 問題3：Mapping 中有超級多字段，僅 includes 就有：41 個字段。

Mapping 中包含過多字段，尤其是查詢時 _source 包含大量字段，會增加查詢負擔。

原因：

（1）I/O 開銷大

每次查詢需要從磁盤讀取大量字段數據，增加了 I/O 開銷。

（2）網絡傳輸慢

返回的數據量大，增加了網絡傳輸時間，影響響應速度。

（3）內存消耗大

在返回大量字段數據（41個字段的數據）時，會占用較多內存，影響系統性能。

建議解決方案：

（1）按需返回字段

僅在 _source 中包含必要的字段，減少數據量。例如，只包含用戶實際需要顯示或處理的字段。

（2）字段分類管理

將常用字段和不常用字段分開管理，常用字段可以集中存儲和索引，不常用字段可以進行更高效的壓縮和存儲。

Elasticsearch 8.x 存儲有無壓縮？能壓縮到多少？

（3）動態字段處理

考慮使用動態字段（借助運行時字段實現）或字段別名，在需要時動態擴展，而不是在 Mapping 中預先定義所有可能的字段。

4.3 No search context found for id [XXXXXXX]，報錯：236次。

如下錯誤：

org.elasticsearch.search.SearchContextMissingException: No search context found for id [208049]，

在 13 分 2.973 秒內共發生 236 次。

圖片

這表明在執行 Scroll 查詢時，某些查詢上下文已經丟失或超時。

[2024-08-02T12:05:44,520][DEBUG][o.e.a.s.TransportSearchScrollAction] [slave] [208049] Failed to execute query phase
org.elasticsearch.transport.RemoteTransportException: [slav1][172.17.0.1:29302][indices:data/read/search[phase/query/scroll]]
Caused by: org.elasticsearch.search.SearchContextMissingException: No search context found for id [208049]

4.3.1 “上下文丟失”可能的原因分析

查詢上下文過期 Scroll 查詢上下文默認在保持不活動狀態下只會持續一段時間（默認 1 分鐘）。如果查詢處理時間超過此時間，上下文會被清除，從而導致此錯誤。
高并發導致上下文管理混亂在高并發場景下，大量 Scroll 查詢請求可能導致系統無法及時管理和維護這些上下文，造成上下文丟失。
節點重啟或崩潰執行 Scroll 查詢的節點如果在查詢過程中重啟或崩潰，會導致查詢上下文丟失。

4.3.2 解決方案

方案1：增加 Scroll 上下文的保持時間

需要排查咱們做了啥？

在 Scroll 查詢請求中增加 scroll 參數，例如設置為 5 分鐘：

{
  "scroll": "5m"
}

根據查詢復雜度和數據量調整保持時間，確保足夠長的時間完成查詢。

如果數據量不大或可以分段處理，使用常規分頁查詢代替 Scroll 查詢，減少對上下文的依賴。

方案二：優化查詢性能簡化查詢條件，減少不必要的計算，提升查詢速度。

如前所述，“空間換時間”，預先計算和緩存部分查詢結果，減少實時計算量。

5、非主節點日志“逆向分析”

除了類似主節點報錯外，非主節點報錯如下:

[2024-08-02T17:41:21,517][WARN 


org.elasticsearch.cluster.block.ClusterBlockException: blocked by: [SERVICE_UNAVAILABLE/2/no master];

圖片

大致推測：[2024-08-02T17:41:21,517] 主節點宕機了。

5.1 問題描述

上述日志報錯表明 Elasticsearch 集群當前沒有主節點（master node）。

在 Elasticsearch 集群中，主節點負責管理集群狀態和元數據（例如索引和節點信息）。如果集群中沒有主節點，整個集群會變得不可用，導致無法執行任何操作，包括索引和查詢。

5.2 原因猜測

主節點故障：當前主節點可能已經發生故障或崩潰（猜測就是第4部分分析的，扛不住壓力導致宕機）。
資源不足：主節點所在的物理機器資源不足（如內存、CPU），導致主節點崩潰。

6、小結

通過合理配置和優化，Elasticsearch 集群的性能問題是可以逐步解決的。

但，爆改集群默認配置是不建議的。

關鍵在于合理分配資源，優化查詢和索引操作，同時結合監控工具和日志分析，及時發現并解決潛在問題。

希望上述分析和建議能夠幫助大家更好地管理和優化 Elasticsearch 集群，提高系統的穩定性和響應速度。

第一部分提到的集群配置、節點角色劃分、分片大小、文檔大小、文檔映射、檢索語句、監控指標等都值得進一步深入探討......

責任編輯：武曉燕來源：銘毅天下Elasticsearch

集群配置日志