elasticsearch 弹性传输请求超出限制

我们有一个7.2弹性集群，节点如下。 6数据节点 3主节点 2摄取节点

最近，我们在弹性日志中观察到以下错误。 似乎默认限制是[986061209/940.3mb]，但实际使用量（[990145976/944.2mb]）远不止此。请告知我们是否有将传输请求大小增加到986061209以上的配置

[2020-02-04T00:37:24464][DEBUG][o.e.a.a.c.n.i.TransportNodesInfo][blp06742225]未能在节点[64OKIQjOQ6WaVWNQgW lTQ]上执行 org.elasticsearch.transport.RemoteTransportException:[blp06742240][10.52.54.95:61025][cluster:monitor/nodes/info[n]] 原因：org.elasticsearch.common.breaker.CircuitBreakingException:[父项]数据太大，[]的数据将为[9901526/944.2mb]，大于[986061209/940.3mb]的限制，实际使用量：[990145976/944.2mb]，保留新字节：[6550/6.3kb] 在org.elasticsearch.index.breaker.HierarchyCircuitBreakerService.checkParentLimit（HierarchyCircuitBreakerService.java:343）~[elasticsearch-7.2.1.jar:7.2.1] 在org.elasticsearch.common.breaker.ChildMemoryCircuitBreaker.AddEstimateBytes和MaybebeBreak（ChildMemoryCircuitBreaker.java:128）~[elasticsearch-7.2.1.jar:7.2.1] 在org.elasticsearch.transport.InboundHandler.handleRequest（InboundHandler.java:173）[elasticsearch-7.2.1.jar:7.2.1] 在org.elasticsearch.transport.InboundHandler.messageReceived（InboundHandler.java:121）[elasticsearch-7.2.1.jar:7.2.1] 在org.elasticsearch.transport.InboundHandler.inboundMessage（InboundHandler.java:105）[elasticsearch-7.2.1.jar:7.2.1] 在org.elasticsearch.transport.tcpttransport.inboundMessage（tcpttransport.java:660）[elasticsearch-7.2.1.jar:7.2.1] 在org.elasticsearch.transport.netty4.Netty4MessageChannelHandler.channelRead（Netty4MessageChannelHandler.java:62）[transport-netty4-client-7.2.1.jar:7.2.1] 在io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead（AbstractChannelHandlerContext.java:374）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead（AbstractChannelHandlerContext.java:360）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.AbstractChannelHandlerContext.fireChannelRead（AbstractChannelHandlerContext.java:352）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead（ByteToMessageDecoder.java:323）[netty-codec-4.1.35.Final.jar:4.1.35.Final] 在io.netty.handler.codec.ByteToMessageDecoder.channelRead（ByteToMessageDecoder.java:297）[netty-codec-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead（AbstractChannelHandlerContext.java:374）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead（AbstractChannelHandlerContext.java:360）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.AbstractChannelHandlerContext.fireChannelRead（AbstractChannelHandlerContext.java:352）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.handler.logging.LoggingHandler.channelRead（LoggingHandler.java:241）[netty-handler-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead（AbstractChannelHandlerContext.java:374）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead（AbstractChannelHandlerContext.java:360）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.AbstractChannelHandlerContext.fireChannelRead（AbstractChannelHandlerContext.java:352）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead（DefaultChannelPipeline.java:1408）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead（AbstractChannelHandlerContext.java:374）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead（AbstractChannelHandlerContext.java:360）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.DefaultChannelPipeline.fireChannelRead（DefaultChannelPipeline.java:930）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.nio.AbstractNioByteChannel$niobyteensafe.read（AbstractNioByteChannel.java:163）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.nio.NioEventLoop.processSelectedKey（NioEventLoop.java:682）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain（NioEventLoop.java:582）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.nio.NioEventLoop.processSelectedKeys（NioEventLoop.java:536）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 在io.netty.channel.nio.NioEventLoop.run（NioEventLoop.java:496）[netty-transport-4.1.35.Final.jar:4.1.35.Final] 位于io.netty.util.concurrent.SingleThreadEventExecutor$5.run（SingleThreadEventExecutor.java:906）[netty-common-4.1.35.Final.jar:4.1.35.Final] 在io.netty.util.internal.threadexecutomap$2.run（threadexecutomap.java:74）[netty-common-4.1.35.Final.jar:4.1.35.Final]

---

在java.lang.Thread.run（Thread.java:835）[？：？]

中，原因是节点的堆非常满，并且被断路器捕获，这很好，因为它可以防止节点运行到oom中，过时并崩溃

Elasticsearch 6.2.0引入了断路器，并在7.0.0中对其进行了改进

其中一个节点

（64OKIQJOQ6WAVWWNQGW lTQ）

已被另一个节点请求对其碎片执行搜索或（批量）索引操作，但由于内存不足而失败。根据此错误消息，这里的情况正是如此：

Data too large, data for [] would be [990152526/944.2mb], which is larger than the limit of [986061209/940.3mb], real usage: [990145976/944.2mb], new bytes reserved: [6550/6.3kb]