弹性传输请求超过限制

Question

我们有 7.2 弹性集群和下面的节点。 6 数据节点 3 主节点 2摄取节点

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

[2020-02-04T00:37:24,464][DEBUG][o.e.a.a.c.n.i.TransportNodesInfoAction] [blp06742225] 无法在节点 [64OKIQjOQ6WaVWNQgW-lTQ] 上执行 org.elasticsearch.transport.RemoteTransportException：[blp06742240][10.52.54.95:61025][cluster:monitor/nodes/info[n]] 原因：org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [] will be [990152526/944.2mb], 大于[986061209/940.3mb]的限制，实际用法： [990145976/944.2mb]，保留新字节：[6550/6.3kb] 在 org.elasticsearch.indices.breaker.HierarchyCircuitBreakerService.checkParentLimit(HierarchyCircuitBreakerService.java:343) ~[elasticsearch-7.2.1.jar:7.2.1] 在 org.elasticsearch.common.breaker.ChildMemoryCircuitBreaker.addEstimateBytesAndMaybeBreak(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.TcpTransport.inboundMessage(TcpTransport.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$NioByteUnsafe.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.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.35.Final.jar:4.1.35.Final] 在 java.lang.Thread.run(Thread.java:835) [?:?]

Answer 1

原因是节点的堆非常满，被断路器捕获，这很好，因为它可以防止节点运行到 OOM，变得陈旧和崩溃......

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

另一个节点已请求其中一个节点(64OKIQjOQ6WaVWNQgW-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]

还要注意 Stackrace 中涉及的类和方法的名称：

org.elasticsearch.common.breaker.ChildMemoryCircuitBreaker.addEstimateBytesAndMaybeBreak(ChildMemoryCircuitBreaker.java:128)

如果您无法增加堆或减少节点持有的数据，则需要扩展集群。

以下是一些背景信息：

https://www.elastic.co/guide/en/elasticsearch/reference/current/circuit-breaker.html

https://www.elastic.co/blog/improving-node-resiliency-with-the-real-memory-circuit-breaker

如果您需要快速解决方案，请尝试使用文档中描述的 api 增加断路器限制。但请记住，这根本不能解决问题。