JVM-Tuning für Elasticsearch-Performance: Tipps zu Heap und Garbage Collection

Elasticsearch läuft auf der JVM, daher sind Heap und Garbage Collection wichtig. Aber JVM-Tuning ist nicht der erste Ansatz, wenn ein Cluster langsam ist. Überprüfen Sie zuerst die Shard-Anzahl, die Query-Form, den Indizierungsdruck, die Festplattenlatenz und ob der Knoten einfach zu klein dimensioniert ist. JVM-Einstellungen sind wichtig, weil schlechte Werte einen gesunden Cluster instabil machen können. Sie sind kein Ersatz für schlechtes Index-Design oder überlastete Hardware.

Dieser Leitfaden konzentriert sich auf Elasticsearch JVM-Tuning, das im täglichen Betrieb noch nützlich ist: Heap-Größenbestimmung, Symptome der Garbage Collection, Speicherdruck und die praktischen Überprüfungen, die Ihnen sagen, ob Java wirklich das Problem ist.

Grundlegendes zu den Speicheranforderungen von Elasticsearch

Elasticsearch benötigt Speicher für zwei Hauptbereiche: Heap-Speicher und Off-Heap-Speicher. Richtiges Tuning beinhaltet die korrekte Einstellung des Heaps und die Sicherstellung, dass das Betriebssystem genügend physischen Speicher für Off-Heap-Anforderungen übrig hat.

1. Heap-Speicherzuweisung (`ES_JAVA_OPTS`)

Der Heap ist der Ort, an dem Elasticsearch-Objekte, Indizes, Shards und Caches gespeichert werden. Es ist die kritischste Einstellung.

Festlegen der Heap-Größe

Elasticsearch empfiehlt dringend, die anfängliche Heap-Größe (-Xms) gleich der maximalen Heap-Größe (-Xmx) zu setzen. Dies verhindert, dass die JVM den Heap dynamisch skaliert, was zu spürbaren Leistungspausen führen kann.

Best Practice: Die 50%-Regel

Weisen Sie niemals mehr als 50% des physischen RAM dem Elasticsearch-Heap zu. Der verbleibende Speicher ist entscheidend für den Dateisystem-Cache des Betriebssystems (OS). Das OS verwendet diesen Cache, um häufig aufgerufene Indexdaten (invertierte Indizes, gespeicherte Felder) von der Festplatte zu speichern, was deutlich schneller ist als das Lesen von der Festplatte.

Empfehlung: Wenn ein Rechner 64 GB RAM hat, setzen Sie -Xms und -Xmx auf 31g oder weniger.

Konfigurationsort

Diese Einstellungen werden typischerweise in der Datei jvm.options im Elasticsearch-Konfigurationsverzeichnis (z.B. $ES_HOME/config/jvm.options) oder über Umgebungsvariablen konfiguriert, wenn Sie die Einstellungen lieber extern verwalten möchten (z.B. mit ES_JAVA_OPTS).

Beispielkonfiguration (in jvm.options):

# Anfängliche Java-Heap-Größe (z.B. 30 Gigabyte)
-Xms30g

# Maximale Java-Heap-Größe (muss mit -Xms übereinstimmen)
-Xmx30g

Warnung zur Heap-Größe: Vermeiden Sie es, die Heap-Größe über 31 GB (oder etwa 32 GB) zu setzen. Dies liegt daran, dass eine 64-Bit-JVM komprimierte Objektzeiger (Compressed Oops) für Heaps verwendet, die kleiner als ~32 GB sind, was zu speichereffizienteren Objektlayouts führt. Das Überschreiten dieser Schwelle hebt diesen Effizienzvorteil oft auf.

2. Off-Heap-Speicher (Direkter Speicher)

Elasticsearch verwendet auch Speicher außerhalb des Java-Heaps. Lucene verlässt sich stark auf den Betriebssystem-Page-Cache, und Elasticsearch kann direkten Speicher für Netzwerk- und native Operationen verwenden. In den meisten Installationen sollten Sie -XX:MaxDirectMemorySize nicht setzen, es sei denn, die Elastic-Dokumentation oder Support-Anleitung für Ihre genaue Version und Workload sagt dies. Ein manuelles Limit für direkten Speicher kann eine neue Fehlerquelle schaffen, wenn es zu niedrig ist oder auf einer veralteten Annahme basiert.

Garbage Collection (GC)-Tuning

Garbage Collection ist der Prozess, bei dem die JVM Speicher zurückgewinnt, der von nicht mehr referenzierten Objekten verwendet wird. In Elasticsearch kann eine schlecht verwaltete GC zu erheblichen Latenzspitzen führen, die oft als "Stop-the-World"-Pausen bezeichnet werden, was zu Knoten-Timeouts und Instabilität führen kann.

Auswahl des richtigen Collectors

Moderne Elasticsearch-Versionen werden mit unterstützten JVM-Standards ausgeliefert und verwenden im Allgemeinen G1GC auf gängigen aktuellen Java-Versionen. Behandeln Sie diese Standards als Ausgangsbasis. Ändern Sie Collector-Einstellungen nur, wenn Logs und Metriken ein echtes Problem mit der Garbage Collection zeigen.

G1GC-Tuning-Parameter

Der primäre Parameter für die G1GC-Optimierung ist die Festlegung des maximalen Pausenzeit-Ziels. Dies teilt dem Collector mit, wie aggressiv er Speicher bereinigen soll.

Beispiel G1GC-Konfiguration:

# Nur Beispiel: Fügen Sie keine GC-Flags hinzu, es sei denn, Ihre Version unterstützt sie
# und Sie haben Beweise, dass das Standardverhalten das Problem ist.
-XX:MaxGCPauseMillis=200

Überwachung der GC-Aktivität

Effektives Tuning erfordert zu wissen, wann GC läuft und wie lange es dauert. Elasticsearch ermöglicht es Ihnen, GC-Ereignisse direkt in eine Datei zu protokollieren, was für die Fehlerbehebung bei Latenzproblemen unerlässlich ist.

Aktivieren der GC-Protokollierung:

Fügen Sie diese Flags zu Ihrer jvm.options-Datei hinzu, um eine detaillierte GC-Protokollierung zu aktivieren:

# GC-Protokollierung aktivieren
-Xlog:gc*:file=logs/gc.log:time,level,tags

# Optional: Log-Rotationsgröße angeben (z.B. nach 10 MB rotieren)
-Xlog:gc*:file=logs/gc.log:utctime,level,tags:filecount=10,filesize=10m

Analysieren Sie die resultierende gc.log-Datei mit Tools wie GCEasy oder spezifischen Skripten, um Folgendes zu identifizieren:

Häufigkeit: Wie oft GC läuft.
Dauer: Die Länge der Pausen (Total time for GC in...).
Promotion-Rate: Wie viele Daten überleben lange genug, um in die alte Generation zu wechseln.

Wenn GC-Pausen konsistent das MaxGCPauseMillis-Ziel überschreiten (z.B. häufig 500 ms oder mehr erreichen), deutet dies auf Speicherdruck hin. Lösungen umfassen die Erhöhung der Heap-Größe (wenn RAM es erlaubt, unter Einhaltung der 50%-Regel) oder die Optimierung von Indizierungs-/Query-Mustern, um den Objektumschlag zu reduzieren.

Praktischer Tuning-Workflow und Best Practices

Befolgen Sie diesen systematischen Ansatz, um Ihre Elasticsearch JVM-Einstellungen zu tunen:

Schritt 1: Knotenkapazität bestimmen

Identifizieren Sie den gesamten physischen RAM, der auf dem Rechner verfügbar ist, der den Elasticsearch-Knoten hostet.

Schritt 2: Heap-Größe berechnen

Berechnen Sie die maximale Heap-Größe: Max Heap = Physical RAM * 0,5 (abgerundet auf den nächsten sicheren Bruchteil, normalerweise mit 1-2 GB freiem Puffer). Setzen Sie -Xms und -Xmx auf diesen Wert.

Schritt 3: Direkten Speicher in Ruhe lassen, es sei denn, Sie haben einen Grund

Kopieren Sie keine Direktspeicher-Flags aus alten Blogbeiträgen. Überprüfen Sie zuerst die Dokumentation Ihrer Elasticsearch-Version und die aktuellen Startprotokolle.

Schritt 4: GC konfigurieren

Stellen Sie sicher, dass -XX:+UseG1GC vorhanden ist, und erwägen Sie, ein vernünftiges Ziel wie -XX:MaxGCPauseMillis=100 zu setzen.

Schritt 5: Protokollierung aktivieren und überwachen

Aktivieren Sie die GC-Protokollierung und lassen Sie den Cluster mehrere Stunden oder Tage unter einer typischen Produktionslast laufen. Überprüfen Sie die Protokolle.

Schritt 6: Basierend auf Protokollen iterieren

Wenn Pausen zu lang sind: Möglicherweise müssen Sie die Indizierungslast reduzieren oder, wenn RAM es erlaubt, die Heap-Größe leicht erhöhen und die 50%-Regel neu bewerten.
Wenn GC sehr häufig läuft, aber Pausen kurz sind: Ihr Heap könnte etwas zu klein sein, was zu übermäßigen Minor Collections führt, oder Sie erstellen zu viele kurzlebige Objekte.

Tipp zur Shard-Größe: JVM-Tuning funktioniert am besten in Kombination mit geeigneten Indizierungsstrategien. Übermäßige Sharding (zu viele kleine Shards) zwingt die JVM, eine massive Anzahl von Objekten über viele Strukturen hinweg zu verwalten, was den GC-Overhead erhöht. Zielen Sie auf größere Shards (z.B. 10 GB bis 50 GB), um den Overhead pro Knoten zu reduzieren.

Wie Heap-Druck in echten Clustern aussieht

Heap-Druck kündigt sich selten als "Heap-Druck" bei der diensthabenden Person an. Er zeigt sich als Suchlatenzspitzen, Indizierungsablehnungen, langsame Clusterstatus-Updates, Knoten, die den Cluster verlassen und wieder beitreten, oder Dashboards, die gut aussehen, bis der Datenverkehr Spitzen erreicht. Das nützliche Signal ist, ob der JVM-Heap ansteigt, die Garbage Collection läuft und der Heap danach wieder auf ein gesundes Niveau zurückfällt.

Wenn der Heap während einer geschäftigen Periode ansteigt und nach der Garbage Collection wieder abfällt, arbeitet der Knoten möglicherweise einfach hart. Wenn der Heap ansteigt und nach Sammlungen der alten Generation hoch bleibt, haben Sie möglicherweise anhaltenden Druck. Wenn lange GC-Pausen mit Knotentrennungen, Master-Wahlen oder Client-Timeouts zusammenfallen, ist das JVM-Verhalten wahrscheinlich Teil des Vorfalls.

Verwenden Sie Elasticsearch-Knotenstatistiken, um das JVM-Verhalten zu überprüfen:

curl -s "http://localhost:9200/_nodes/stats/jvm,indices,thread_pool?pretty"

Überprüfen Sie den prozentualen Heap-Verbrauch, die Anzahl und Zeit der Garbage Collection, den Fielddata-Speicher, den Request-Cache, den Query-Cache, den Indizierungsdruck und abgelehnte Thread-Pool-Aufgaben. Eine einzelne Metrik kann in die Irre führen. Zum Beispiel kann ein hoher Heap ohne abgelehnte Aufgaben weniger dringend sein als ein moderater Heap mit Suchablehnungen und langen Pausen der alten Generation.

Die 50-Prozent-Regel hat einen Grund

Der allgemeine Rat, den Elasticsearch-Heap bei oder unter etwa der Hälfte des System-RAMs zu halten, ist nicht willkürlich. Lucene liest Indexdateien von der Festplatte, und der Betriebssystem-Page-Cache macht wiederholte Lesevorgänge viel schneller. Wenn Sie fast den gesamten Speicher der JVM geben, mag der Heap großzügig aussehen, während die Suchleistung schlechter wird, weil das OS heiße Segmente nicht effektiv cachen kann.

Auf einem 64-GB-Knoten ist ein Heap von etwa 30 GB oder 31 GB eine übliche Obergrenze. Auf einem 16-GB-Knoten könnten 8 GB ein Ausgangspunkt sein. Auf einem kleinen Entwicklungsknoten kann Elasticsearch mit viel weniger laufen. Der richtige Wert hängt von der Workload, der Version und der Knotenrolle ab. Dedizierte master-fähige Knoten benötigen normalerweise viel weniger Heap als heiße Datenknoten. Koordinierende Knoten können einen sinnvollen Heap benötigen, wenn sie große Suchanfragen ausgeben und große Antworten zusammenführen.

Erhöhen Sie den Heap nicht nur, weil der Heap manchmal hoch ist. Fragen Sie zuerst, was ihn verwendet. Zu viele Shards, teure Aggregationen, große Fielddata, große Bulk-Anfragen, riesige Suchergebnisfenster und ein schwerer Clusterstatus können den Heap nach oben treiben. Eine Erhöhung des Heaps kann das Symptom verzögern, während das zugrunde liegende Design immer schlechter wird.

Komprimierte Objektzeiger und die 32-GB-Falle

Viele Java-Bereitstellungen vermeiden Heaps über etwa 32 GB, weil die JVM möglicherweise komprimierte gewöhnliche Objektzeiger (oft als Compressed Oops bezeichnet) verliert. Wenn das passiert, können Objektreferenzen mehr Speicher belegen, und der zusätzliche Heap bringt möglicherweise nicht so viel nutzbaren Speicher wie erwartet. Der genaue Grenzwert kann variieren, überprüfen Sie daher die Startprotokolle, anstatt 32 GB als magische Zahl zu behandeln.

Elasticsearch protokolliert die JVM-Ergonomie während des Starts. Wenn Sie nahe an der Schwelle sind, bestätigen Sie, ob Compressed Oops aktiviert ist. Ein Heap von 31g wird oft gewählt, um mit etwas Sicherheitsmarge unter der Grenze zu bleiben. Wenn ein Knoten wirklich viel mehr Speicher benötigt, ist es möglicherweise besser, Knoten hinzuzufügen, den Shard-Druck zu reduzieren oder Rollen zu trennen, anstatt einen riesigen Heap mit schmerzhaftem GC-Verhalten zu erstellen.

Shards, Mappings und Queries können JVM-Probleme verursachen

JVM-Tuning kann einen Cluster nicht vor übermäßigen Shard-Anzahlen retten. Jeder Shard hat Overhead: Datenstrukturen, Segment-Metadaten, Caches, Suchkoordination und Wiederherstellungsarbeit. Tausende winziger Shards können Heap verbrauchen und Cluster-Operationen verlangsamen, selbst wenn jeder Shard sehr wenig Daten enthält. Wenn Ihr Heap-Problem nach dem Hinzufügen vieler täglicher Indizes aufgetreten ist, könnte die Lösung Index Lifecycle Management und Shard-Konsolidierung sein, nicht ein GC-Flag.

Mappings sind ebenfalls wichtig. Textfelder, Keyword-Felder, Doc Values, Fielddata, verschachtelte Dokumente und Runtime-Felder haben unterschiedliches Speicherverhalten. Das Aktivieren von Fielddata auf großen Textfeldern kann besonders teuer sein. Wenn der Heap während Aggregationen springt, überprüfen Sie, ob Benutzer auf Feldern aggregieren, die nicht dafür ausgelegt sind.

Queries können Speichernutzungsspitzen verursachen. Tiefe Paginierung mit großen from-Werten, breite Wildcard-Queries, Aggregationen mit hoher Kardinalität und große Ergebnismengen setzen sowohl koordinierende als auch Datenknoten unter Druck. Verwenden Sie search_after, Point-in-Time-Suchen, engere Filter und gut gestaltete Aggregationen, wo sie passen. Eine Query, die sich in der Entwicklung harmlos anfühlt, kann schlimm sein, wenn sie über Hunderte von Shards läuft.

Bulk-Indizierung und Heap

Bulk-Indizierung ist eine weitere häufige Quelle von Verwirrung. Größere Bulk-Anfragen können den Durchsatz bis zu einem gewissen Punkt verbessern, aber überdimensionierte Anfragen verbrauchen Speicher, erhöhen die Wartezeit und machen Wiederholungen teurer. Wenn Sie Indizierungsdruck, Write-Thread-Pool-Ablehnungen oder GC-Spitzen während der Aufnahme sehen, reduzieren Sie die Bulk-Anfragegröße oder Parallelität, bevor Sie JVM-Flags ändern.

Ein praktischer Ansatz ist, Bulk-Größen mit produktionsähnlichen Dokumenten zu testen. Beginnen Sie bescheiden, erhöhen Sie, bis der Durchsatz nicht mehr steigt, und gehen Sie dann zurück. Beobachten Sie CPU, Heap, GC, Festplatten-I/O, Merge-Aktivität und Ablehnungszahlen. Wenn der Knoten die meiste Zeit mit dem Zusammenführen von Segmenten oder dem Warten auf die Festplatte verbringt, wird Heap-Tuning den Aufnahme-Engpass nicht beheben.

Das Aktualisierungsintervall beeinflusst auch das Indizierungsverhalten. Für starke Aufnahme, bei der keine Echtzeitsuche erforderlich ist, kann die Erhöhung von refresh_interval den Segmentumschlag reduzieren. Das ist eine Indexeinstellung, kein JVM-Tuning, aber es verbessert oft die Symptome, die man der JVM zuschreibt.

Container-Speicherlimits

Elasticsearch in Containern erfordert besondere Aufmerksamkeit, da die JVM Containerlimits je nach Java-Version und Konfiguration unterschiedlich sieht. Wenn der Container ein 4-GB-Speicherlimit hat und Sie einen 4-GB-Heap setzen, kann der Prozess trotzdem getötet werden, weil Off-Heap-Speicher, Thread-Stacks, nativer Speicher und Dateisystem-Cache ebenfalls Platz benötigen.

Setzen Sie den Heap relativ zum Container-Speicherlimit, nicht zum Host-Speicher. Lassen Sie Platz für Nicht-Heap-Speicher. Achten Sie auf OOMKilled-Ereignisse in Kubernetes oder Container-Laufzeitprotokollen. Ein Pod, der ohne sauberen Elasticsearch-Fehler verschwindet, wurde möglicherweise von der Plattform getötet, anstatt in Java abzustürzen.

Für Kubernetes sollten Requests und Limits das tatsächliche Speicherprofil widerspiegeln. Ein Limit, das zu nah am Heap liegt, lädt zu OOM-Kills ein. Ein Request, der zu niedrig ist, kann den Pod auf einen Knoten platzieren, wo er stark mit anderen Workloads konkurriert. Elasticsearch profitiert mehr von vorhersagbarem Speicher und Festplatten-I/O als von opportunistischem Overcommit.

Wann GC-Einstellungen geändert werden sollten

Die meisten Betreiber sollten Collector-Experimente vermeiden. Elasticsearch testet und liefert unterstützte JVM-Einstellungen für jede Version mit. Das zufällige Hinzufügen alter CMS-Flags, aggressiver Pausenziele oder kopierter Tuning-Pakete kann den Start verhindern oder das Verhalten verschlechtern.

Ändern Sie GC-Einstellungen nur, nachdem Sie das Problem in Protokollen beschreiben können: GC-Pausen der alten Generation sind zu lang, GC der jungen Generation ist zu häufig, der Heap erholt sich nicht, oder Pausenereignisse fallen mit Cluster-Instabilität zusammen. Auch dann bevorzugen Sie kleine Änderungen und behalten Sie einen Rollback-Pfad. JVM-Flags sind Teil der Produktionskonfiguration und sollten denselben Überprüfungsprozess durchlaufen wie Shard-Allokation oder Sicherheitsänderungen.

Wenn Sie ein Pausenziel wie MaxGCPauseMillis ändern, denken Sie daran, dass es ein Ziel ist, kein Versprechen. Die JVM kann es unter starkem Allokationsdruck möglicherweise nicht erreichen. Wenn die Anwendung zu viele Objekte zu schnell erstellt, kann der Collector das nicht in freie Leistung umwandeln.

Eine kurze Incident-Checkliste

Wenn Elasticsearch-Latenzspitzen auftreten und die JVM verdächtigt wird, würde ich diese in der Reihenfolge überprüfen:

Sind ein oder zwei Knoten ungesund, oder ist der gesamte Cluster betroffen?
Ist die Heap-Nutzung gleichzeitig mit der Latenz gestiegen?
Gab es GC-Pausen der alten Generation, und wie lange waren sie?
Lehnen Such- oder Schreib-Thread-Pools Arbeit ab?
Haben sich die Indizierungsrate, Bulk-Größe oder das Query-Volumen geändert?
Sind Shard-Anzahl, Segment-Anzahl oder Clusterstatus-Größe kürzlich gewachsen?
Ist die Festplatten-I/O-Latenz hoch?
Hat eine Bereitstellung, Mapping-Änderung oder neue Dashboard-Query etwa zur gleichen Zeit begonnen?

Diese Checkliste hält die Untersuchung fundiert. JVM-Tuning ist ein Hebel, aber es ist einer von mehreren Hebeln.

Die praktische Erkenntnis

Richtige JVM-Einstellungen helfen Elasticsearch, stabil zu bleiben, aber die meisten Erfolge kommen von der sorgfältigen Dimensionierung des Heaps, dem Freilassen von Platz für den Dateisystem-Cache, der Beobachtung des tatsächlichen GC-Verhaltens und der Behebung von Shard- oder Query-Problemen, die Speicherdruck verursachen. Halten Sie -Xms und -Xmx gleich, bleiben Sie konservativ nahe der Compressed-Oops-Schwelle, vertrauen Sie den Versionsstandards, bis Beweise etwas anderes sagen, und behandeln Sie GC-Protokolle als operative Beweise und nicht als Dekoration.