問題背景

客戶方面反饋的問題是ES入庫速度變慢，延遲升高到幾百毫秒，導致數據積壓過多，影響了業務。

排查發現ES的服務日志出現不少的gc overhead現象，下面是一個示例的日志片段：

[yyyy-MM-ddTHH:mm:ss,SSS][LEVEL][component][node_name][gc][gc_id] overhead, 
spent [time_spent] collecting in the last [total_time], [additional_info] 
例如： [2023-06-15T14:30:00,000][WARN][o.e.m.j.JvmGcMonitorService][node-01][gc][1234] overhead, 
spent [2.5s] collecting in the last [3.0s], [heap used=70% of 10GB]

在這個例子中，日志表明在過去的3秒內，JVM用掉了2.5秒來進行垃圾回收，這可能是一個警告信號，表示GC活動過于頻繁或者每次GC暫停時間過長，可能導致應用程序性能下降或響應遲鈍。

如果這種情況持續，可能會觸發“GC Overhead Limit Exceeded”錯誤，進而導致服務不穩定甚至崩潰。

解決方案

排查思路：

• 查看日志，查看并分析Elasticsearch日志中的GC詳細信息，包括GC類型
• 詢問業務的使用類型，業務的數據量，通過監控查看ES的搜索、寫入的負載情況
• 根據實際情況對JVM參數進行適當調整。

最終發現三個問題：

1. 并發搜索居高不下，日常保持在1000個查詢并發，但集群規模較小。
2. 大的索引未拆分，且分片數過少，數據分布不均存在讀寫的熱點。
3. 磁盤性能不高，由于讀寫壓力都比較大，磁盤使用率很高

由于業務側代碼不便更改，便采取優化服務端參數的辦法，經過調優對比，我統計了調優前后各1天的日志內容，統計發現，gc發生率顯著下降了85%，且結合索引的拆分操作，最終延遲下降了20倍。

分享參數如下：

ES的G1GC參數（多實例適用）

-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=40
-XX:+ParallelRefProcEnabled
-XX:+ExplicitGCInvokesConcurrent
-XX:ParallelGCThreads=8

注：該參數同樣適用于HBase集群的參數調優，效果已經在實際環境中經過驗證！

參數介紹：

• -XX:+UseG1GC：啟用G1垃圾收集器。
• -XX:MaxGCPauseMillis=200：設置最大GC暫停時間為200毫秒。這個值可以根據實際情況進行調整，以實現更好的系統性能。
• -XX:InitiatingHeapOccupancyPercent=35：當堆的使用率達到35%時，G1垃圾收集器將啟動混合收集。這個值也可以根據實際情況進行調整。
• -XX:+ParallelRefProcEnabled：啟用并行引用處理。
• -XX:+ExplicitGCInvokesConcurrent：顯式GC調用并發處理。

思考

在Elasticsearch環境下，垃圾回收的效率直接影響著索引速度、查詢延遲以及總體系統吞吐量。當GC工作過于頻繁或執行時間過長時，就會出現“gc overhead”警報，這意味著GC活動占用了大量CPU資源，使得應用程序的實際處理能力下降，嚴重時甚至會導致響應時間延長、服務不可用等問題。因此，正確配置JVM的GC參數是Elasticsearch性能調優的關鍵步驟之一。

那么，有廣泛適用的推薦配置值嗎？

由于具體的應用場景和需求差異較大，很難給出適用于所有情況的推薦配置值。建議根據應用的具體需求和性能測試結果來調整上述參數。例如，可以先使用默認配置進行性能測試，然后根據性能測試結果逐步調整-Xmx、-XX:MaxGCPauseMillis和-XX:InitiatingHeapOccupancyPercent等關鍵參數，以達到最佳的性能表現。

G1GC的配置是一個復雜的過程，需要綜合考慮應用的需求、硬件資源、性能目標等多個因素。在實際操作中，建議結合官方文檔、性能測試結果和社區經驗來進行配置和優化。