2016-04-28 58 views
0

我的ES 2.3.1实例使用了它的堆的97%,因此几乎不断地收集垃圾,并防止任何请求成功。事情是,我无法弄清楚什么东西在吃掉所有的记忆。根本没有field_data的用法。Elasticsearch因使用Groovy脚本而使用大量内存

这是我的node stats

如果我可以提供更多信息,请让我知道。任何帮助,将不胜感激。谢谢!

编辑:

这是基于关闭Elasticsearch JVM堆泄漏嫌疑报表的屏幕截图。它似乎是一个与groovy脚本相关的内存泄漏。这是Elasticsearch本身的问题吗?或者有可能我在客户端做错了什么? leak suspects report

编辑:

下面是我使用的脚本。这一个替换给定ID只要更新值的嵌套对象的当前版本不陈旧:

def found = false; 
if (ctx._source.my_field != null) { 
    for (int i = 0; i < ctx._source.my_field.size(); i++) {  
     if (ctx._source.my_field[i].id == 1) {  
      found = true;  
      if (ctx._source.my_field[i].timestamp < 201605011912488050) {   
       ctx._source.my_field[i] = jsonMap  } 
      else {   
       ctx.op = "none"  
      }  
     } 
    }; 
    if (!found) { 
     ctx._source.my_field += jsonMap; 
    } 
} else { 
    ctx._source.my_field = [jsonMap]; 
}; 

这一个简单的更新定期场如果更新不陈旧:

if (ctx._source.my_field2 == null || ctx._source.my_field2.timestamp < 201605011913320690) { 
    ctx._source.my_field2 = jsonMap 
} else { 
    ctx.op = "none" 
} 

在上述两种情况下,我使用通过地图传入的json对象更新字段(如建议的here)。我创建并通过在地图上用下面的代码:

Map<?, ?> jsonMap = new ObjectMapper().readValue(updateJson.toString(), HashMap.class); 
Map<String, Object> params = ImmutableMap.of("jsonMap", jsonMap); 
return new Script(script, ScriptService.ScriptType.INLINE, null, params); 

编辑:信息的

一些更多的位:

1)第一个脚本,通过循环嵌套文档的数量通常是O(1)并且不超过O(10)。

2)要运行脚本,我首先创建一个updateRequest:

UpdateRequest updateRequest = new UpdateRequest() 
    .index(index) 
    .type(documentType) 
    .id(documentId.toString()) 
    .script(script) 
    .retryOnConflict(5) 
    .upsert(getIndexRequestForDocumentUpsert(...)); 

其中getIndexRequestForDocumentUpsert(...)只返回一个简单的(非脚本)指数这将是一个新的文档请求。然后将这些UpdateRequest添加到批量更新请求中,该请求最多包含100个更新。 3)最后,需要注意的一件重要的事情是,在对索引进行任何更新(或查询)之后2天进行堆转储,这是它泄漏的原因,而不是纯粹的过度负载。

+0

确实无法从统计数据中知道。我建议采取堆转储并使用yourkit或Eclipse MAT来查看其内容。 –

+0

@AndreiStefan增加了内存分析器泄漏嫌疑人报告的截图。你认为值得在Github上打开一个问题吗? – PeteyPabPro

+0

你正在用一些Groovy脚本在客户端做很重的事情。 –

回答

0

我在Github上打开了issue,显然这是由于已知的Groovy内存泄漏造成的。