#大数据/ES #经验 #性能
问题背景
客户方面反馈的问题是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参数进行适当调整。
最终发现三个问题：
- 并发搜索居高不下，日常保持在1000个查询并发，但集群规模较小。
- 大的索引未拆分，且分片数过少，数据分布不均存在读写的热点。
- 磁盘性能不高，由于读写压力都比较大，磁盘使用率很高
由于业务侧代码不便更改，便采取优化服务端参数的办法，经过调优对比，我统计了调优前后各1天的日志内容，统计发现，gc发生率显著下降了85%，且结合索引的拆分操作，最终延迟下降了20倍，分享参数如下：
ES的G1GC参数（多实例适用）
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=40
-XX:+ParallelRefProcEnabled
-XX:+ExplicitGCInvokesConcurrent
-XX:ParallelGCThreads=8
注：该参数同样适用于HBase集群的参数调优，效果已经在实际环境中经过验证！
配置时的报错
切记！注意行尾不能带任何空格或者乱七八糟的换行符！
否则可能遇到如下启动失败报错（行尾有空格，没注意到）：
Unrecognized VM option 'UseG1GC '
Did you mean '(+/-)UseG1GC'?
参数介绍：
-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的配置是一个复杂的过程，需要综合考虑应用的需求、硬件资源、性能目标等多个因素。在实际操作中，建议结合官方文档、性能测试结果和社区经验来进行配置和优化。
