降低85%的gc发生率:ES的GC调优实践!

#大数据/ES #经验 #性能

问题背景

客户方面反馈的问题是ES入库速度变慢,延迟升高到几百毫秒,导致数据积压过多,影响了业务。

排查发现ES的服务日志出现不少的gc overhead现象,下面是一个示例的日志片段:

shell 复制代码
[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参数(多实例适用)

yaml 复制代码
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=40
-XX:+ParallelRefProcEnabled
-XX:+ExplicitGCInvokesConcurrent
-XX:ParallelGCThreads=8

注:该参数同样适用于HBase集群的参数调优,效果已经在实际环境中经过验证!

配置时的报错

切记!注意行尾不能带任何空格或者乱七八糟的换行符!

否则可能遇到如下启动失败报错(行尾有空格,没注意到):

shell 复制代码
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的配置是一个复杂的过程,需要综合考虑应用的需求、硬件资源、性能目标等多个因素。在实际操作中,建议结合官方文档、性能测试结果和社区经验来进行配置和优化。

相关推荐
冼紫菜2 小时前
[特殊字符]实战:使用 Canal + MQ + ES + Redis + XXL-Job 打造高性能地理抢单系统
java·redis·分布式·后端·elasticsearch·rabbitmq·全文检索
碎梦归途3 小时前
23种设计模式-行为型模式之备忘录模式(Java版本)
java·jvm·设计模式·软考·备忘录模式·软件设计师·行为型模式
程序员沉梦听雨11 小时前
【Elasticsearch】入门篇
大数据·elasticsearch·搜索引擎
Gadus_11 小时前
Elasticsearch性能优化实践
大数据·elasticsearch·搜索引擎·性能优化
九酒12 小时前
性能优化:500w字符编码需要多少时间?
前端·性能优化
八股文领域大手子15 小时前
如何给GitHub项目提PR(踩坑记录
大数据·elasticsearch·github
爱吃龙利鱼15 小时前
elk中kibana一直处于可用和降级之间且es群集状态并没有问题的解决方法
大数据·elk·elasticsearch
腾讯云大数据15 小时前
腾讯云ES一站式RAG方案获信通院“开源大模型+软件创新应用”精选案例奖
大数据·elasticsearch·开源·云计算·腾讯云
苍煜15 小时前
Elasticsearch(ES)中的脚本(Script)
大数据·elasticsearch·搜索引擎
Elastic 中国社区官方博客16 小时前
使用 LangGraph 和 Elasticsearch 构建强大的 RAG 工作流
大数据·数据库·人工智能·elasticsearch·搜索引擎·ai·全文检索