elasti c transport_request больше лимита

Question

У нас есть 7,2 эласта c кластера с нижним узлом. 6 Узел данных 3 Узел магистрали 2 Узел приема

Недавно мы наблюдали ошибку ниже в наших журналах elasti c. Похоже, что предел по умолчанию составляет [986061209 / 940.3mb], но реальное использование ([990145976 / 944.2mb]) более того. Пожалуйста, дайте нам знать, есть ли какая-либо конфигурация для увеличения размера transport_request выше 986061209.

[2020-02-04T00: 37: 24,464] [DEBUG] [oeaa c .niTransportNodesInfoAction] [blp06742225] не удалось выполнить на узел [64OKIQjOQ6WaVWNQgW-lTQ] org.elasticsearch.transport.RemoteTransportException: [blp06742240] [10.52.54.95:61025] [кластер: монитор / узлы / информация [n]] Причина: org.elasticsearch.common.itingingC. parent] Данные слишком большие, данные для [] будут [990152526 / 944.2mb], что больше, чем предел [986061209 / 940.3mb], реальное использование: [990145976 / 944.2mb], зарезервированы новые байты: [6550 / 6,3 КБ (ChildMemoryCircuitBreaker. java: 128) ~ [asticsearch-7.2.1.jar: 7.2.1] в org.elasticsearch.transport.InboundHandler.handleR equest (InboundHandler. java: 173) [asticsearch-7.2.1.jar: 7.2.1] в org.elasticsearch.transport.InboundHandler.messageReceived (InboundHandler. java: 121) [asticsearch-7.2.1.jar : 7.2.1] в org.elasticsearch.transport.InboundHandler.inboundMessage (InboundHandler. java: 105) [asticsearch-7.2.1.jar: 7.2.1] в org.elasticsearch.transport.TcpTransport.inboundMessage (TcpTransport. java: 660) [asticsearch-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 (AbstractChannel. : 352) [netty-transport-4.1.35.Final.jar: 4.1.35.Final] по адресу io.netty.handler.code c .ByteToMessageDecoder.fireChannelRead (ByteToMessageDecoder. java: 323) [нетти-код c -4.1.35.Final.jar: 4.1.35.Final] на io.netty.handler.code c .ByteToMessageDecoder.channelRead (ByteToMessageDecoder. java: 297) [netty-код c - 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.AbstractChannelHandlerContextadhanChannel (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) -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.fireChannelPadlinePad (по умолчанию ( . 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.NioEventL oop .processSelectedKey (NioEventL oop. java: 682) [netty-transport- 4.1.35.Final.jar: 4.1.35.Final] на io.netty.channel.nio.NioEventL oop .processSelectedKeysPlain (NioEventL oop. java: 582) [netty-transport-4.1.35. Final.jar: 4.1.35.Final] на io.netty.channel.nio.NioEventL oop .processSelectedKeys (NioEventL oop. java: 536) [netty-transport-4.1.35.Final.jar: 4.1.35.Final] на io.netty.channel.nio.NioEventL oop .run (NioEventL oop. 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 (Тема. java: 835) [?:?]

Answer 1

Причина в том, что куча узла довольно заполнена и перехватывается автоматическим выключателем, что приятно, поскольку она предотвращает попадание узлов в OOM, устаревание и кр sh ...

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, описанный в документации. Но имейте в виду, что это не решает проблему вообще.