JVM-Grundlagen für Elasticsearch: Metriken, Speicher und Monitoring

Elasticsearch ist eine Java-basierte Such- und Analytics Engine sowie Vektordatenbank, die auf Apache Lucene basiert und den Kern der Elasticsearch Platform bildet. Um Elasticsearch auf den unterstützten Plattformen auszuführen, benötigen Sie eine Java-virtuelle Maschine (JVM). Die JVM bietet eine Platform-unabhängige Laufzeitumgebung, und Sie können Elasticsearch in einer virtuellen Umgebung auf dem vorhandenen Betriebssystem ausführen. Die JVM abstrahiert das zugrundeliegende Betriebssystem und die Hardware, sodass Java-Anwendungen auf jeder Platform ausgeführt werden können.

Das Verständnis der Speicherverwaltung der JVM und der Objektbereinigung mittels Garbage Collection (GC) ist der Schlüssel zur Fehlersuche bei Problemen wie java.lang.OutOfMemoryError (Exit-Code 127). Diese Probleme treten auf, wenn die JVM keinen Speicher mehr ausführt oder ein Exit-Code 137 vorliegt, was in der Regel darauf hinweist, dass der Out-of-Memory (OOM) Killer des Hosts den JVM-Prozess aufgrund übermäßiger Speichernutzung beendet hat. Dieser Blog zeigt Ihnen, wie Sie die Muster der Speichernutzung untersuchen und diese JVM-Probleme beheben können.

Ich werde auch die Rolle der JVM erläutern und wie diese mithilfe bestehender Elasticsearch-APIs korreliert werden kann. Dies liefert wertvolle Einblicke in den Zustand der Elasticsearch-JVM und hilft Ihnen bei der Entscheidung, ob Sie diese weiter an Ihren eigenen Anwendungsfall anpassen möchten. 

Wie in der Elasticsearch JVM-Dokumentation erwähnt, funktionieren die Standardwerte der JVM-Optionen, die mit dem Produkt versendet werden, effizient in allen unterstützten Produktionsumgebungen; diese Standardwerte können die meisten Anwendungsfälle für Such- und Indexierungsvorgänge abdecken. Es wird nicht empfohlen, Werte zu ändern oder benutzerdefinierte Werte für die JVM-Optionen oder -Einstellungen hinzuzufügen.

Eine Java virtuelle Maschine ist ein integraler Bestandteil der Java Runtime Environment (JRE), die im Java Development Kit (JDK) enthalten ist.

Die JVM ähnelt einem Computerprogramm, das beim Ausführen von Java-Anwendungen hilft. Sie existiert nicht als physische Maschine, fungiert aber wie eine, indem sie Java-Code in Anweisungen übersetzt, die Ihr unterstütztes Betriebssystem verstehen kann. Die JVM kümmert sich zudem um wichtige Aufgaben wie Speicherverwaltung, die Handhabung der Garbage Collection und die Sicherheit Ihrer Anwendungen.

Als Nächstes konzentrieren wir uns auf die JVM-Speicherverwaltung und die Garbage Collection – ein wichtiger Punkt in Elasticsearch, den wir bei der Fehlerbehebung von Problemen mit der Speicherleistung oder OOM-bezogenen Problemen häufig überprüfen.

Um die Speicherverwaltung und Garbage Collection zu verstehen, müssen Sie zunächst die logische Darstellung des Heap-Bereichs (oder Heap-Speichers) verstehen, in dem sich alle Objekte befinden, wenn eine JVM startet.

Flächendiagramm/Region der Young Generation
Wenn eine Java-Anwendung startet, erstellt sie neue Objekte und weist diese dem Flächendiagramm zu, das als Heap-Speicher bezeichnet wird. Der Eden-Bereich der Young Generation ist der erste Ort, an dem die Anwendung neu erstellte Objekte zuweist. Dieses Flächendiagramm ist für die Zuweisung neuer Objekte reserviert. Wenn es voll ist, werden die berechtigten Objekte entweder bereinigt (Garbage Collection) oder in andere Regionen verschoben.

Wenn eine kleine Garbage Collection stattfindet, werden die referenzierten Objekte in einen anderen Unterabschnitt verschoben, den Survivor-Bereich S0. Die nicht referenzierten Objekte werden gelöscht, um den Speicherplatz in Eden freizugeben. Dieser Bereich enthält die Objekte, die den Garbage-Collection-Prozess überlebt haben, daher der Name Survivor-Bereich. 

Der gleiche Zyklus wiederholt sich, wenn der Eden-Space wieder voll ist. Diesmal werden die Objekte, die sowohl Eden als auch S0 überlebt haben, in die S1-Region verschoben, und dieser Prozess setzt sich fort. 

Die Objekte, die die Garbage Collections in Eden, S0 und S1 überlebt haben, werden basierend auf dem Altersrechner in die Old Generation befördert.

Flächendiagramm/Region der Old Generation
Die Old Generation (auch als Tenured Generation bekannt) ist eine Sammlung langlebiger Objekte, die mehrere Garbage-Collection-Ereignisse in der Young Generation (Minor GCs) überlebt haben. Objekte, die eine bestimmte Anzahl von Zyklen im Survivor-Space überlebt haben, werden vom Algorithmus in die Old Generation verschoben, was auch als Objekt-Promotion bezeichnet wird.

Das obige sägezahnartige GC-Muster aus der Stack-Überwachung zeigt, dass der JVM-Heap-Speicher während der Minor-Garbage-Collection reduziert wird, da der GC die unerwünschten Objekte aus dem Speicher entfernt. Nach einigen Zyklen sammeln sich Objekte an und der GC wird erneut aktiv, um die Objekte zu bereinigen. 

Der G1GC hat ein Ziel für die Pausenzeit (-XX:MaxGCPauseMillis=200), das er während der Garbage Collection einzuhalten versucht. Das bedeutet, dass er während der Garbage Collection sicherstellt, dass die JVM keine längere Pause als diesen Wert erfährt, was ihn besser macht als CMS oder andere Collector, bei denen dies keine Option ist. Insgesamt wird empfohlen, die GC-Einstellungen auf den Standardwerten zu belassen, wodurch die GC-Pause für eine verbesserte Leistung innerhalb der Grenzwerte gehalten wird.

Diese API liefert Details zur Node-Konfiguration, einschließlich JVM-Eingangsargumenten, Speicherpools und Heap-Größe. 

Wenn Sie zusätzlich die Metriken der Elasticsearch-JVM für die Uptime eines bestimmten Node, den in allen Speicherpools verwendeten Heap oder Statistiken zur Garbage Collection überprüfen möchten, können Sie die Node-Statistik -API verwenden. Sie liefert detaillierte Metriken zu jedem der genannten Punkte.

Wenn Sie ein fortgeschrittener Nutzer sind und Echtzeitstatistiken zu einer laufenden JVM ohne die Verwendung von Elasticsearch-APIs abrufen möchten, können Sie das mitgelieferte Java verwenden und jstat ausführen, um die Live-Statistiken zu überprüfen. Suchen Sie hierzu zunächst das Java-Home-Verzeichnis oder das bin-Verzeichnis sowie die PID des Elasticsearch-Prozesses. Verwenden Sie aus dem bin-Verzeichnis das Tool jstat:

Hierbei ist 2000 das Intervall in Millisekunden, nach dem die Statistiken abgerufen und auf der CLI ausgegeben werden. Dieser Befehl ist hilfreich, um zu ermitteln, wie häufig die GC in allen Bereichen stattfindet und wie schnell Speicherpools durch Objekte gefüllt werden (Raten für Objekterstellung und -promotion). 

Dies ist keine Alternative zu den oben genannten APIs, sondern dient eher dem Debugging auf Entwicklerebene.

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.