简体   繁体   English

ElasticSearch Java TransportClient泄漏byte []

[英]ElasticSearch Java TransportClient leaking byte[]

ElasticSearch Java TransportClient 5.5.1 seems to be leaking byte arrays. ElasticSearch Java TransportClient 5.5.1似乎泄漏了字节数组。 Even if i just connect and close, commenting the code in between, it leaks. 即使我只是连接并关闭,在其间评论代码,它也会泄漏。

The code: 编码:

try (PreBuiltTransportClient preBuiltTransportClient = new PreBuiltTransportClient(settings)) {
     try(TransportClient transportClient=preBuiltTransportClient.addTransportAddress(
            new InetSocketTransportAddress(InetAddress.getByName(endPoint),javaPort))){
         //do something
     }
}

Plugin loading log (may indicate something): 插件加载日志(可能表示某些内容):

加载插件日志 VisualVM Heap dump showing byte[] allocated size on the heap (after forcing a garbage collection): VisualVM堆转储显示堆上的byte []已分配大小(强制执行垃圾回收后):

VisualVM的

Seems to be the same problem as posted here: https://discuss.elastic.co/t/are-there-memory-leaks-in-elasticsearchs-transportclient-5-4-3-or-is-my-code-flawed/91989/5 似乎与此处发布的问题相同: https//discuss.elastic.co/t/are-there-memory-leaks-in-elasticsearchs-transportclient-5-4-3-or-is-my-code-有缺陷的/5分之91989

Not sure if relevant, but I am using Spring boot on the same project. 不确定是否相关,但我在同一个项目上使用Spring启动。

Any ideas? 有任何想法吗?

EDIT: 编辑:

Seems to be related to Compression: 似乎与压缩有关:

在此输入图像描述

EDIT2: EDIT2:

The memory consumption increases greatly on TransportClientNodesService.addTransportAddresses TransportClientNodesService.addTransportAddresses的内存消耗大大增加

Solution here: https://github.com/elastic/elasticsearch/issues/26048 解决方案: https//github.com/elastic/elasticsearch/issues/26048

It's not a leak, it's from netty pooled allocator. 它不是泄漏,而是来自netty池化分配器。

Set io.netty.allocator.type=unpooled to disable. 将io.netty.allocator.type = unpooled设置为禁用。

System.setProperty("io.netty.allocator.type", "unpooled");

OR 要么

-Dio.netty.allocator.type=unpooled 

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM