经常发生节点OOM的问题。

排查问题产生的原因，以及解决方案。

如何提高堆的利用率？

目前线上OOM节点挂的事情经常发生。

关于堆的问题分析，我们应该从这几个方向去分析：堆里都装着什么？能不能减少。 是什么原因导致OOM的？什么类型的请求。

发生oom的时候堆内存快照分析

ES千亿级检索实战 堆OOM 问题深度分析_水的精神的博客-CSDN博客

解决方案

业务上的不正当使用导致的堆占用高

首先排除业务上的使用问题。不合理的请求。

例如：很多 from 0 size 10000的请求。这在小规模索引下，没有什么问题，一旦命中索引数超过2000，就会非常的糟糕。在大索引（分片数非常多）的情况下，要控制单个请求取回的数据。size最好不要超过1000，甚至更小。同是更应该注意from的值，尽可能也控制在1000以内。否则是一件非常危险的事情。它会非常的花费堆资源。如果真的有需求出很多数据，可以考虑滚动查询。

例如：query_string中的检索词，有500多个，这个会很耗时！一直占用堆空间，不能释放。

设置超时时间，两分钟的超时时间，如果出不来数据，就不再返回数据。

哪些需求可以离线计算？哪些需求从es角度触发必须离线？让es只出必须对实时性要求高的需求，其它的聚合分析，可以考虑大数据平台的离线计算。

如果有条件，就扩集群

偶尔的OOM还好，但是频繁的OOM已经不正常了。在排除掉业务上的不正当的需求以后，假如堆还是有很大的压力。这个时候已经需要加资源了。我们一定要清楚，我们的集群当前在保证检索性能的前提下的处理能力的极限。因为集群的每个节点能够承载能力是有限的，堆的承载能力也是有限的。我们在设计上要保证集群中的数据流动起来，例如只存储三个月的数据，每天有数据进来，也有数据流出集群。这样保证集群真的只存三个月的数据。

集群的处理能力总是有限的，应该对进入es中的请求，有个准确的评估。然后适当的去做限流。

以上两个思路是防止集群越运行越慢的方法。

如果没有条件扩展，可以调参

这是一个迫不得己的操作，无非是在拆东墙补西墙！换句话说，也算资源充分利用吧。

可以调整es堆内存分配！

指针压缩失效临界值

目前我们线上的机器是每个节点给31G内存。这肯定不是最大的，看到腾讯的给es31.8G，网上还要其它人说临界值是32g - 1M要测一下临界值是多少。修改线上配置。

在70这台测试机器上，测试的临界值是 31.96G，我们可以给到临界值，可以提升将近1G的堆空间。这个多出来将近1G的空间。

测试方法参考官方文档：

堆内存:大小和交换 | Elasticsearch: 权威指南 | Elastic

indexBufferPool

默认是10%堆空间，写满flash。能不能调小一些，多少是合理的，不影响线上的写入。调小可能写入会降速。要进行具体的测试。如果堆31G，百分之十也有3.1G了。假如调成百分之五，那么又节省出来1.5G堆空间。

queryCache

默认是10%堆空间，用作查询缓存。因为很多请求，都是filter包起来的，这部分很容易会被缓存起来，这部分，能不能不缓存。我们必须做有效的缓存，否则很多不生效的，会让缓存效果更差。

fieldDataMemory

默认是30%的堆空间，可以调小一点。我们生产环境因为堆空间不足，给了10%。

这部分是用作，keyword类型的聚合，它会存全局序数。它还会被用作sort。

从使用方面，我们应该避免无效的sort。

段合并减少 segmentMemory的空间

这部分效果不会太大。因为目前来看，这部分占用不是很大。

在介绍了这些内存以后，可以通过下边的参数来查看堆中都有什么

GET _cat/nodes?v&h=id,ip,port,r,ramPercent,ramCurrent,heapMax,heapCurrent,fielddataMemory,queryCacheMemory,requestCacheMemory,segmentsMemory

节点角色规划

以下是协调节点的JVM的使用情况。在分析OOM的时候，发现在错误日志中有部分的coordination的错误

当前节点的角色不带协调节点，但是带了远程节点的角色。在执行跨集群的时候，此节点会充当协调节点。

在OOM以后看到最多的日志就是的下边图片上的warn级别的日志。

[o.e.t.InboundHandler     ] [10.99.100.10-2] handling inbound transport message [InboundMessage{Header{2912}{7.11.1}{38434969561}{true}{false}{false}{false}{indices:data/read/search[can_match]}}] took [6606ms] which is above the warn threshold of [5000ms]

然后分析，来看，InboundHandler都是用来接受数据的，再根据当前节点的角色不带协调节点角色，只带着remote节点角色。

找到和报错信息相关的es源码，看打印出来的都是什么内容：

协调角色节点的堆的使用情况，基本上只正常的。我认为可以通过es 将数据节点中的remote角色可以都给协调节点。来分担数据节点的堆的压力。

源码级别的修改，精准分析堆内存的占用， 调整堆占用，部分挪出堆

下边是腾讯在2020年做的，将FST挪出了堆，目的为了提高单个节点能够承载的数据量。这项优化，在es6.8及以下版本是非常有效的。但是到了Es 7.X版本，已经默认把FST从堆内挪到堆外了！

腾讯万亿级 Elasticsearch 内存效率提升技术解密 - 知乎

这个不适用我们，我们的方向大概是将缓存挪出堆。