CircuitBreakingException вasticsearch: как настроить транспортный буфер? - PullRequest
Новая
       25

CircuitBreakingException вasticsearch: как настроить транспортный буфер?

1 голос
/ 07 апреля 2019

CircuitBreakingException вasticsearch: как настроить транспортный буфер?

Я борюсь сasticsearch, версия 6.4.0. У каждого узла была утечка памяти. Они повторили старый GC, но куча не была очищена. Я обнаружил несколько журналов ниже в тот момент. Похоже, утечка памяти произошла после этого CircuitBreakingException

[2019-04-02T19:24:35,411][ERROR][o.e.x.m.c.c.ClusterStatsCollector] [master node] collector [cluster_stats] timed out when collecting data
[2019-04-02T19:24:37,023][WARN ][o.e.a.b.TransportShardBulkAction] [master node] [index name][1]] failed to perform indices:data/write/bulk[s] on replica [index name][1], node[XXX], [R], s[STARTED], a[id=XXX]
org.elasticsearch.transport.RemoteTransportException: [data node][XXXXXXX][indices:data/write/bulk[s][r]]
Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [11905569825/11gb], which is larger than the limit of [11854931558/11gb], usages [request=332816/325kb, fielddata=9381528467/8.7gb, in_flight_requests=144866/141.4kb, accounting=2523563676/2.3gb]
        at org.elasticsearch.indices.breaker.HierarchyCircuitBreakerService.checkParentLimit(HierarchyCircuitBreakerService.java:240) ~[elasticsearch-6.4.0.jar:6.4.0]
        at org.elasticsearch.common.breaker.ChildMemoryCircuitBreaker.addEstimateBytesAndMaybeBreak(ChildMemoryCircuitBreaker.java:128) ~[elasticsearch-6.4.0.jar:6.4.0]
        at org.elasticsearch.transport.TcpTransport.handleRequest(TcpTransport.java:1553) [elasticsearch-6.4.0.jar:6.4.0]
        at org.elasticsearch.transport.TcpTransport.messageReceived(TcpTransport.java:1427) [elasticsearch-6.4.0.jar:6.4.0]
        at org.elasticsearch.transport.netty4.Netty4MessageChannelHandler.channelRead(Netty4MessageChannelHandler.java:64) [transport-netty4-6.4.0.jar:6.4.0]

Я знаю, что OOM не произошло из-за этого автоматического выключателя, но мне интересно , почему главный узел пытался транспортировать большие данные, подобные этому . Каждый узел начинал с этой опции JVM о пространстве кучи. 

-Xms16g
-Xmx16g

Все конфиги в elasticsearch.yml по умолчанию, включая indices.breaker.total.limit, indices.memory.index_buffer_size. Размер буфера индекса по умолчанию составляет 10% от общей кучи, поэтому он составил 1,6 ГБ. Но главный узел пытался перевезти более 11G одновременно, согласно журналу. Есть ли какое-нибудь решение вместо простого увеличения кучи?

...