一次ElasticSearch集群jvm占用高的排查解决过程

最新推荐文章于 2026-04-15 20:35:27 发布
原创 最新推荐文章于 2026-04-15 20:35:27 发布 · 1.4k 阅读 · 26 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
标签
#elasticsearch #大数据 #搜索引擎

目录

一、问题现象

二、问题排查过程

1、查看flink日志

2、查看es集群日志

3、ES集群jvm内存占用分析

4、jvm的GC 占比分析

5、jvm dump文件分析

三、总结

一、问题现象

项目上使用flink将实时数据写入ES,随着每天数据的逐渐增多，最近出现flink程序经常性挂掉的现象，导致数据出现积压和延迟。

二、问题排查过程

1、查看flink日志

     首先查看flink任务的运行状态和日志，发现flink的CheckPoint失败频繁，一旦失败的次数达到指定的值任务就会重启，短时间内任务频繁重启,如下图所示：

通过flink任务的背压分析，发现是写入ES超时失败导致的，排查ES集群所在的服务器cpu负载、内存使用、磁盘和网络负载，发现均正常。

2、查看es集群日志

继续查看es节点的日志，发现下面的报错：

org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, date tor [indices:data/write/bulk[s]] would be [31702096886/29.5],which is large than the limit of ......

这个报错就说明es出现了内存熔断的现象，es集群为了防止出现OOM的问题，有内存熔断的机制，如果jvm的内存使用量超过95%，则会拒绝所有的读写请求。

在kibana中查看ES集群资源占用情况，cpu和load负载都不高，发现各节点的jvm的使用率在90%左右，属于异常现象，如下图所示：

3、ES集群jvm内存占用分析

既然是jvm占用高，那就得分析出jvm中哪部分数据占用的内存高，对ES内存模型中的常用的index buffer、queryCache、requestCache、fieldDataCache、segmentsCache做内存占用分析，可在kibana中执行如下命令获取内存占用情况：

GET /_cat/nodes?v&h=name,port,sm

GET /_cat/nodes?v=true&h=name,heap*,fielddata.memory_size,query_cache.memory_size,request_cache.memory_size

得出结果如下：

内存类型

占用量

index buffer

3g (默认最大是占用jvm的10%，按照最大来算)

queryCache

1.2g

requestCache

500mb

fieldDataCache

1.5g

segmentsCache

260mb

index buffer是写入时候的缓存，默认是jvm的10%，es集群配置的jvm是31g，按照最大占用3g来算，加在一起也不过6.5g,才占用了21%左右，也就是说有将近70%的jvm不知道被谁占用了，非常奇怪。

4、jvm的GC 占比分析

    继续对jvm的GC做深层次的分析，找出到底是谁在占用大量的jvm。

在es节点的服务器上执行命令： jstat -gc  8021 5000

   其中8021是es服务的进程号，5000是每隔5000毫秒打印一次，如下图所示：

发现GC的老年代使用量OU达到了惊人的28143964 KB,也就是26.8GB,且长期不释放，这就是明显出现了内存泄漏的问题。

5、jvm dump文件分析

既然定位到老年代里有对象占用内存长期没有释放，就要做进一步的分析到底是被哪些对象占用。

借助jmap命令来生成dump文件，分析内存中对象的信息。

在es节点服务器上执行命令: jmap -dump:format=b,file=es-dump.dump 8021

其中es-dump.dump 是生成的dump文件名，8021是es服务的进程号。

然后将es-dump.dump 文件从服务器下载到本地，用VisualVM软件载入dump文件。

然后点击类，再点击大小，按照占用大小倒序排序，如下图所示：

很明显可以看到 float[ ] 、int[ ]、byte[ ] 三个类型的数组加起来占到了jvm的83%

继续分析三种数组的引用关系，发现都是被包含HanLP的类引用，如下图所示：

  因为ES集群中使用了HanLP分词插件，到这里就基本破案了，可以确定这次es的内存泄漏是由HanLP插件导致，随着数据的增多，HanLP生成的相关数据加载到内存中越来越多并且不释放，当内存使用量达到95%以后，es发生内存熔断，所有读写请求均被拒绝，使es集群处于崩溃不可用状态。

将HanLP插件从es集群中移除，重启集群，es各节点的jvm的使用量稳定在较低的水平，集群读写速度也恢复到正常情况。

三、总结

 排查类似jvm内存占用高等有关内存泄漏的问题，均可以使用类似上述gc的分析方法，先查看gc的年轻代和老年代的占比情况，然后在对jvm的dump文件做对象占用分析，基本可以定位到问题所在。

【Elasticsearch】Elasticsearch CPU高排查思路
九师兄
10-25 3197
1.概述 https://blog.csdn.net/laoyang360/article/details/79874984 https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-above.html#ignore-above https://discuss.elastic.co/t/es-high-cpu-usage-when-idle/87950/4
Elasticsearch:CPU使用率间歇性陡增解决方案
智者千虑，必有一失；愚者千虑，必有一得。
08-23 1959
elasticsearch集群cpu每间隔10min飙高一次问题追踪
Elasticsearch (ES)内存管理降低内存占用率
洛秋的博客
05-29 2851
是 Elasticsearch 中存储文档字段值的一种数据结构，用于支持聚合、排序、脚本和其他操作。在 Elasticsearch 中，文档中的每个字段都可以被索引，并且可以被搜索和分析。当你执行聚合操作、排序、或者使用脚本时，Elasticsearch 需要对字段数据进行处理。Field data 缓存存储了字段数据的一部分或全部内容，以便于快速访问和处理。这样，当你执行相同的操作时，Elasticsearch 可以直接从缓存中获取字段数据，而不必每次都从磁盘或者内存中重新加载。
Elasticsearch-高CPU优化
NCS123456的博客
06-21 2326
Elasticsearch使用线程池管理CPU资源，用于并发操作。如果某个节点的CPU使用率很高，可以使用该节点的热线程API（hot_threads）来检查节点上运行的资源密集型线程。如图所示，查询请求量的波动与集群最大CPU使用率是基本吻合的。确保对于节点上已配置的每个 GB的内存，将分片数量保持在 20 以下，如果某个节点拥有 30GB 的堆内存，那其最多可有 600 个分片。查看查询/写请求量，分析是否cpu高和查询量升高或者写入量升高导致的。是操作系统层面的cpu消耗，不是我们重点优化对象。
ES堆占用高问题分析与解决方案
Angus
09-25 8321
千亿级检索，ES JVM参数调优，解决OOM问题。
ElasticSearch集群内存占用高？如何降低内存占用看这篇文章就够啦！（冻结索引）
小赵的博客
11-16 4000
经常搜索的索引被保留在内存中，因为重建索引和帮助高效搜索需要花费时间。另一方面，可能存在我们很少访问的索引。这些。这样的索引称为。每当搜索分片时，Elasticsearch都会构建冻结索引的每个分片的即时数据结构，并在搜索完成后立即丢弃这些数据结构。因为Elasticsearch不会在内存中维护这些临时数据结构，所以冻结索引消耗的堆要比普通索引少得多。与其他方式相比，这允许更高的磁盘与堆的比率。
Elasticsearch 内存占用排查指南
喝醉酒的小白
06-04 1881
通过以上方法和指标，可全面排查和优化 Elasticsearch 的内存占用情况，提升集群性能和稳定性。根据实际负载情况，调整各类缓存的大小。如字段数据缓存、查询缓存和请求缓存等，避免缓存占用过多内存。为实际主机名或 IP。合理设置堆内存大小，通常建议不超过物理内存的 50%，且不超过 32 GB。定期清理无用索引和数据，优化段合并，更新配置参数，保持集群高效运行。，字段数据缓存用于加速聚合和排序操作，过多使用会占用大量内存。（脚本编译次数），频繁编译和驱逐会增加内存压力。
elasticsearch 一次性查询数据量过大 jvm内存快速占用满 导致集群无响应
cnamam的博客
07-05 3549
近期因为生产上es集群出现了内存快速占用满、频繁gc、集群无响应的现象，查看集群日志和满查询日志，发现都是因为频繁gc集群无响应后出现的报错、gc高频的警告以及平时不慢的查询报文出现在慢查询日志里。 看kibana的监控，发现内存几乎是在几秒内就占用满，并且满了以后，由于可用内存不足就开始频繁的full gc，cpu居高不下，集群此时基本在无法响应的状态，有遇到这种情况，只能重启才能解决，无法自己恢复，内存虽然已经占用满，但是集群日志中没有OOM的异常，而且出现的概率比较随机。 由于之前没有遇到过这个问题，
Elasticsearch 6.8.23 集群高IO问题排查与优化指南
喝醉酒的小白
09-30 963
定位问题：通过系统工具和Elasticsearch API监控和分析集群状态，定位高IO的具体原因优化写入性能：调整refresh和translog配置，优化批量写入参数优化段合并：调整merge参数，减少小segment生成，合理安排forcemerge操作优化查询性能：避免深分页，优化查询语句，合理使用聚合操作优化存储配置：升级存储硬件，优化磁盘配置，使用冷热架构优化系统资源：优化操作系统和JVM配置，确保系统资源充足且合理分配。
一次ES集群崩溃及恢复过程
SYN_ACK的博客
07-29 1944
生产环境上搭建了一套由Filebeat + Kafka + Logstash + Elasticsearch + Kibana实现的实时日志分析系统。每一台生产服务器上利用Filebeat收集指定的应用日志，作为生产者写入到Kafka中；另一端Logstash作为消费者消费Kafka中的消息，并上报到ES集群中，最终通过Kibana展示日志消息。我们的生产集群一共七台机器专用于运行Elasticsearch集群，其中六台内存大小为62G,一台内存大小为128G。
Elasticsearch集群内存占用高？用这招！
02-21 2341
Elasticsearch为了能够实现高效快速搜索，在内存中维护了一些数据结构，当索引的数量越来越多，那么这些数据结构所占用的内存也会越来越大，这是一个不可忽视的损耗。 使用freeze index可以一定程度上降低内存的占用。
elasticsearch内存占用详细分析
Angus
03-27 8252
内存占用 ES的JVM heap按使用场景分为可GC部分和常驻部分。 可GC部分内存会随着GC操作而被回收； 常驻部分不会被GC，通常使用LRU策略来进行淘汰； 内存占用情况如下图： common space 包括了indexing buffer和其他ES运行需要的class。indexing buffer由indices.memory.index_buffer_size参数控制， 默认最大占用10%，当full up后，该部分数据被刷入磁盘对应的Segments中。这部分空间是可以被回收
【Elasticsearch】 实际生产中的监控及调优
东方鲤鱼 博客
06-20 7029
一个 Elasticsearch 集群至少包括一个节点和一个索引。或者它可能有一百个数据节点、三个单独的主节点，以及一小打客户端节点——这些共同操作一千个索引（以及上万个分片）。不管集群扩展到多大规模，你都会想要一个快速获取集群状态的途径。API 充当的就是这个角色。你可以把它想象成是在一万英尺的高度鸟瞰集群。它可以告诉你安心吧一切都好，或者警告你集群某个地方有问题。
记elasticsearch CPU负载100%问题
superDE009的博客
01-31 5016
elasticsearch CPU100%负载问题解决。文件上传的问题。logtextstructurefinder
ES--解决JVM 堆内存使用率很高的问题
IT利刃出鞘的博客
12-01 3523
本文介绍如何解决ES的JVM 堆内存使用率飙升的问题。
Elasticsearch集群中节点的JVM内存使用率过高，GC频繁如何排查原因和处理？
maxcode
07-21 648
摘要：Elasticsearch集群节点JVM内存使用率过高、GC频繁问题可能由高查询/写入负载、索引设计不合理或GC配置不当导致。可通过检查慢查询日志、分片状态、GC日志和资源使用情况定位原因。解决方案包括优化复杂查询、限制字段缓存、调整写入批量大小、控制分片数量（10-50GB/分片）及优化GC策略。关键操作如使用search_after替代深分页、设置fielddata.cache.size、调整refresh_interval和监控heap_used_percent指标，可有效降低内存压力，提升集群
探究 | Elasticsearch CPU高排查思路
热门推荐
铭毅天下Elasticsearch
04-10 2万+
一、可能导致ES CPU高的原因： 1、复杂的query查询 举例：我这边出现过200个组合wildcard query导致集群down掉的情况； 2、有大量的reindex操作 3、ES版本较低 二、排查思路 2.1、业务场景排查 问自己几个问题？ - 1）集群中数据类型是怎么样的？ - 2）集群中有多少数据？ - 3）集群中有多少节点数、分片数？ - 4）...
ES（Elasticsearch）进程掉线（节点脱离集群）问题
weixin_43949256的博客
08-05 1842
ES（Elasticsearch）进程掉线（节点脱离集群）是常见问题，排查需要系统性地检查多个方面。：先查网络与资源，再看日志与配置，最后分析分片状态。保持集群版本一致和定期维护是预防关键！通过以上步骤，90%的掉线问题可定位。
从一次线上OOM排查说起：我是如何通过禁用fielddata拯救了我们的Elasticsearch集群
最新发布
weixin_30435261的博客
04-15 156
本文详细记录了作者如何通过禁用Elasticsearch中的fielddata功能解决线上OOM故障。当核心ES集群因`content.keyword`字段占用12GB内存而崩溃时，团队发现fielddata机制导致JVM堆内存耗尽。通过对比fielddata与doc_values的差异，实施紧急禁用措施并重建索引迁移到doc_values，最终建立三层防御体系确保集群稳定运行。
Elasticsearch故障排查深度剖析
weixin_42602726的博客
01-12 498
深入讲解Elasticsearch常见故障的定位与解决方法，结合elasticsearch教程中的核心知识点，帮助开发者快速掌握集群异常、查询慢、节点离线等问题的应对策略，提升系统稳定性与运维效率。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值