Elasticsearch, das aufgrund von Groovy-Skripts viel Speicher verwendet

Question

Meine ES 2.3.1-Instanz verwendet 97% ihres Heapspeichers und sammelt daher fast ständig Müll und verhindert, dass Anforderungen erfolgreich sind. Die Sache ist, ich kann nicht herausfinden, was die ganze Erinnerung verschlingt. Es gibt überhaupt keine field_data-Verwendung.

Hier sind meine node stats.

Bitte lassen Sie mich wissen, wenn ich weitere Informationen zur Verfügung stellen kann. Jede Hilfe wäre willkommen. Vielen Dank!

EDIT:

Hier ist ein Leck Verdächtigen Bericht Screenshot der Elasticsearch JVM-Heap basiert. Es scheint ein Speicherleck zu sein, das mit groovigem Scripting zusammenhängt. Ist das ein Problem mit Elasticsearch selbst? Oder ist es möglich, dass ich mit dem Kunden etwas falsch mache?

EDIT:

Hier sind die Skripte ich verwende. Dieses ersetzt eine aktuelle Version eines verschachtelten Objekts mit einer bestimmten ID, solange der Aktualisierungswert ist nicht abgestanden:

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]; 
}; 

Dieses einfach aktualisiert regelmäßig Feld, wenn das Update nicht veraltet ist:

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

In beiden oben genannten Fällen aktualisiere ich das Feld mit einem JSON-Objekt, das über eine Karte übergeben wird (wie vorgeschlagen here). Ich schaffe und mit dem folgenden Code in der Karte vorbei:

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); 

EDIT:

Noch ein paar Bits von Informationen:

1) Die Anzahl der verschachtelten Dokumenten das erste Skript durch Schleifen ist normalerweise O (1) und nicht mehr als O (10).

2), um die Skripte auszuführen, ich bin ein updateRequest zuerst erstellen:

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

wo getIndexRequestForDocumentUpsert(...) nur eine einfache (nicht-Skript) Index Anforderung gibt für das, was ein neues Dokument wäre. Diese UpdateRequests werden dann zu einer Massenaktualisierungsanforderung hinzugefügt, die maximal 100 Aktualisierungen enthält.

3) Schließlich ist eine wichtige Sache zu beachten, dass dieser Heap-Dump 2 Tage nachdem irgendwelche Aktualisierungen (oder Abfragen) an den Index gemacht worden war, deshalb riecht es nach Undichtigkeit, anstatt nur übermäßige Belastung.

Answer 1

Ich öffnete eine issue auf Github und anscheinend ist dies auf ein bekanntes Groovy Memory-Leck zurückzuführen.