Die Verwendung von elasticsearch jvm heap

Ich kann nicht für Ihre genaue Konfiguration sagen, aber um zu wissen, was in Ihrem Heap passiert, können Sie das jvisualvm-Tool (gebündelt mit dem jdk) zusammen mit marvel oder dem bigdesk plugin (meine Präferenz) und die _cat APIs um zu analysieren, was vor sich geht.

Wie Sie richtig bemerkt haben, enthält der Heap drei Hauptcaches, nämlich:

• der Felddatencache : Standardmäßig unbegrenzt, kann aber auch sein gesteuert mit indices.fielddata.cache.size (in Ihrem Fall scheint es etwa 50% des Heaps zu sein, wahrscheinlich aufgrund der Felddaten-Leistungsschalter )
• der Abfrage / Filter-Cache : 10% der Haufen
• der Shard-Anfrage-Cache : 1% des Heap aber standardmäßig deaktiviert

Es gibt eine schöne Mindmap hier (Lob an Igor Kupczyński), die die Rollen von Caches. Das lässt mehr oder weniger ~ 30% des Heaps (1GB in Ihrem Fall) für alle anderen Objektinstanzen, die ES erstellen muss, um richtig zu funktionieren (mehr dazu später).

Hier ist, wie ich in meinem lokalen Umfeld fortgefahren bin. Zuerst habe ich meinen Knoten neu gestartet (mit Xmx1g ) und auf den grünen Status gewartet. Dann habe ich jvisvisualvm gestartet und es in meinen elastischen Suchprozess eingebunden. Ich habe einen Heap-Dump von der Sampler-Registerkarte genommen, damit ich ihn später mit einem anderen Dump vergleichen kann. Mein Heap sieht anfangs so aus (nur 1/3 des bisher maximal zugewiesenen Heaps):

Ich habe auch überprüft, dass meine Felddaten und Filtercaches leer waren:

Nur um sicher zu gehen, habe ich auch /_cat/fielddata ausgeführt, und wie Sie sehen können, gibt es noch keinen Heap, der von den Felddaten verwendet wird, seit der Knoten gerade gestartet wurde.

Dies ist die Ausgangssituation. Jetzt müssen wir das alles etwas aufwärmen, also habe ich meine Back- und Frontend-Apps gestartet, um den lokalen ES-Knoten unter Druck zu setzen.

Nach einiger Zeit sieht mein Heap so aus, dass seine Größe um 300 MB mehr oder weniger zugenommen hat (139 MB -> 452 MB, nicht viel, aber ich habe dieses Experiment auf einem kleinen Dataset ausgeführt)

Meine Caches sind auch ein bisschen auf ein paar Megabytes angewachsen:

An dieser Stelle ich eine andere Heapdump nahm Erkenntnisse darüber zu gewinnen, wie der Haufen entwickelt hatte, habe ich berechnet, um die die Größe der Objekte beibehalten und ich habe sie mit dem ersten Dump verglichen, den ich direkt nach dem Start des Knotens gemacht habe. Der Vergleich sieht so aus:

Unter den Objekten, die in der beibehaltenen Größe zugenommen haben, sind seine üblichen Verdächtigen natürlich Karten und alle cachebezogenen Entitäten. Aber wir können auch die folgenden Klassen finden:

• NIOFSDirectory , die Lucene-Segment-Dateien auf verwendet werden, um zu lesen das Dateisystem
• Viele interne Strings in Form von char-Arrays oder Byte-Arrays
• Doc-Werte bezogene Klassen
• Bit-Sets
• usw.

Wie Sie sehen, hostet der Heap die drei Hauptcaches, ist aber auch die Stelle, an der alle anderen Java-Objekte residieren, die der Elasticsearch-Prozess benötigt und die nicht unbedingt cache-bezogen sind.

Wenn Sie also Ihre Heap-Nutzung steuern wollen, haben Sie offensichtlich keine Kontrolle über die internen Objekte, die ES benötigt, um ordnungsgemäß zu funktionieren, aber Sie können die Größe Ihrer Caches definitiv beeinflussen. Wenn Sie den Links in der ersten Aufzählungsliste folgen, erhalten Sie eine genaue Vorstellung davon, welche Einstellungen Sie einstellen können.

Auch Tuning-Caches sind vielleicht nicht die einzige Option, vielleicht müssen Sie einige Ihrer Abfragen neu schreiben, um besser speicherfreundlich zu sein oder Ihre Analysatoren oder einige Feldtypen in Ihrem Mapping usw. zu ändern. In Ihrem Fall schwer zu sagen mehr Informationen, aber das sollte Ihnen einige Hinweise geben.

Gehen Sie voran und starten Sie jvisualvm auf die gleiche Weise, wie ich es hier getan habe, und lernen Sie, wie Ihr Heap wächst, während Ihre App (Suchen + Indizieren) auf ES trifft und Sie schnell einen Einblick bekommen sollten.

Marvel zeichnet nur einige Instanzen auf dem Heap auf, die in diesem Fall wie Caches überwacht werden müssen.

Die Caches repräsentieren nur einen Teil der gesamten Heap-Nutzung. Es gibt viele andere Instanzen, die den Heap-Speicher belegen, und diese haben möglicherweise kein direktes Plotten auf dieser Marvel-Schnittstelle.

Daher ist nicht jeder in ES belegte Heap nur durch den Cache.

Um die genaue Verwendung von Heap durch verschiedene Instanzen klar zu verstehen, sollten Sie einen Heap-Dump des Prozesses erstellen und ihn dann mit einem Memory Analyzer-Tool analysieren, das Ihnen das genaue Bild liefert.