ES千亿级检索实战 堆OOM 问题深度分析

问题描述

  在特大规模的索引中检索，通常一次检索涉及到的分片数达到2000个左右。加上跨集检索，堆有非常大的压力，OOM的问题经常发生。本篇文章，对线上环境的堆进行深度分析，看看都有什么。

  我使用prifile来分析查看堆快照。并结合目前我对es底层的了解，来分析堆中都有什么。

  但节点JVM相关配置。每个节点给堆31G内存，fieldDataCache 10%，queriesCahce 10% 其它都是默认的。fieldDataCache会随着数据的变多二无限的增大。这里最好给你一个限制。否则堆的可利用空间会非常的低！

问题发现

问题排查

翻看集群日志OverHead 问题

[2022-09-06T09:14:28,482][INFO ][o.e.m.j.JvmGcMonitorService] [10.99.100.10-2] [gc][young][3934559][634925] duration [744ms], collections [1]/[1s], total [744ms]/[10.5h], memory [16.4gb]->[15.5gb]/[31gb], all_pools {[young] [624mb]->[64mb]/[0b]}{[old] [15gb]->[15.2gb]/[31gb]}{[survivor] [833.1mb]->[182.4mb]/[0b]}

节点堆利用率持续高的问题

从某个节点GC情况来看，持续占用很高，下不来。JVM的平均利用率已经来到了85%。

dump该节点的堆快照

jmap -dump:live,format=b,file=dump.hprof 12587
# dump.hprof 是堆快照的文件名
# 12587 是进程id
# ps -ef |grep elasticserch 可以看到进程id号。

对堆快照进行分析

堆快照 39G

使用profile分析堆快照

重点来看堆中的biggest Objects

9个G的缓存

3个G的queryCache + 3个G的fieldData + 3G写缓存

1.4G的页面缓存

关于页面缓存的介绍：

通常，希望将可能被聚合重用的对象提升到老年代，而不是新生代填满后恰巧放到老年代的一些随机的、临时的对象。为了实现这个目标， Elasticsearch实现了一个页面缓存回收器( PageCacheRecycler )，其中被聚合所使用的大数组被保留下来，不会被垃圾回收。默认的页面缓存是整个堆的10%，某些情况下这个值可能太大(例如，有30 GB的堆内存，页面缓存就有3GB了)

2个G的段的元信息

关于这部分内容的详细介绍：

读lucene的索引段代码笔记_源远流长的博客-CSDN博客

其它的分析

可以看到有 byte类型的和long类型的，这部分需要具体点进去，看看

OOM的问题溯源

实际上本身，集群的堆已经处于一个亚健康状态，堆的利用率已经极高了。在特大查询来的时候就特别容易引发OOM。在这种情况下，压倒骆驼的只需要最后一根稻草。通过查看集群日志们已经发现了很多overHead的日志。本次OOM的最后一根稻草就是：很多个检索词的问题，一次检索看到468个检索词。这在千亿级的检索中，加上跨集群检索，特别致命。跨集群查询，返回较多数据，且耗时长，它就需要一直占据堆空间。

解决方案：

• 角色要调整。远程角色也可以单独出来，减轻数据节点的压力。从业务上减少这样的多检索词的请求。
• 问题的本质是堆空间不足。这是集群资源不足。有条件去扩展集群，这个问题也就不会有了。如果不能扩集群，在资源有限的情况下，只能通过调参数，让集群勉强支持。但是此时就不能谈性能的事情了。

在资源有限的情况下，如何调堆

ES堆占用高问题分析与解决方案_水的精神的博客-CSDN博客