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 集群，提高系統的穩定性和響應速度。

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