Optimierung der Elasticsearch-Speichernutzung für Spitzenleistung

Elasticsearch-Speicherprobleme zeigen sich normalerweise als langsame Suchen, lange Garbage-Collection-Pausen, Schutzschalterfehler oder Knoten, die den Cluster verlassen. Die Optimierung der Elasticsearch-Speichernutzung bedeutet, JVM-Heap, Dateisystem-Cache, Shard-Anzahl, Abfrageverhalten und Indizierungsdruck auszugleichen, anstatt nur -Xmx zu erhöhen.

Das Ziel ist einfach: Elasticsearch genügend Heap für Cluster- und Abfragearbeit geben, während genügend RAM für das Betriebssystem übrig bleibt, um Lucene-Segmentdateien zwischenzuspeichern.

Elasticsearch-Speicherkomponenten verstehen

Elasticsearch verwendet Speicher in zwei Hauptbereichen:

JVM-Heap: Enthält Cluster-Metadaten, Indizierungspuffer, Abfragestrukturen, Fielddata (falls aktiviert), Caches und andere Java-Objekte. Zu wenig Heap verursacht Druck und Schutzschalterauslösungen. Zu viel Heap kann die Garbage Collection verlängern und den Dateisystem-Cache aushungern.
Dateisystem-Cache und nativer Speicher: Das Betriebssystem zwischenspeichert Lucene-Indexdateien außerhalb des JVM-Heaps. Elasticsearch verwendet auch nativen Speicher für Netzwerk, Thread-Stacks und speichergemappte Dateien.

JVM-Heap-Größe konfigurieren

Die Heap-Größenanpassung ist die erste Einstellung, die überprüft werden sollte. Elasticsearch verwendet jvm.options-Dateien oder umgebungsspezifische JVM-Optionen, je nachdem, wie es installiert wurde.

`Xms` und `Xmx` zusammen setzen

Setzen Sie -Xms und -Xmx auf denselben Wert, damit die JVM den Heap während des Betriebs des Knotens nicht in der Größe ändert.

Als Faustregel gilt: Halten Sie den Heap bei oder unter etwa der Hälfte des physischen RAMs und vermeiden Sie es, den komprimierten Ordinary-Object-Pointer-Schwellenwert zu überschreiten. In der Praxis bleiben viele Produktionsknoten unter etwa 30 GB Heap, aber Sie sollten den genauen Schwellenwert und die Richtlinien für Ihre Elasticsearch- und JVM-Version überprüfen.

Zum Beispiel:

-Xms4g
-Xmx4g

Dies setzt sowohl den anfänglichen als auch den maximalen Heap auf 4 GB.

Heap-Nutzung überwachen

Verwenden Sie Kibana Stack Monitoring, Prometheus-Exporteure oder die Nodes Stats API:

curl -X GET "localhost:9200/_nodes/stats/jvm?pretty"

Beobachten Sie heap_used_percent, Garbage-Collection-Zeit, Old-Generation-Druck und Schutzschalterauslösungen. Heap, der nach der Garbage Collection über längere Zeit hoch bleibt, bedeutet normalerweise, dass Sie die Heap-Verbraucher reduzieren oder Kapazität hinzufügen müssen.

Shard- und Abfrage-Speicherdruck reduzieren

Indexlayout und Abfrageform haben einen direkten Einfluss auf den Speicher.

Shard-Größe und -Anzahl

Jeder Shard verursacht Overhead. Zu viele winzige Shards verschwenden Heap und verlangsamen Cluster-Operationen. Sehr große Shards können die Wiederherstellung und Verschiebung erschweren. Viele Cluster arbeiten gut mit Shard-Größen im zweistelligen Gigabyte-Bereich, aber Protokolle, Zeitreihendaten und suchintensive Indizes können andere Ziele erfordern.

Wenn beispielsweise ein täglicher Protokollindex 30 Primär-Shards für 20 GB Daten erstellt, zahlen Sie Overhead für viele kleine Shards. Ein oder zwei Primär-Shards können je nach Aufbewahrungs- und Abfragemustern einfacher zu verwalten sein.

Segmentzusammenführung

Elasticsearch verwendet Lucene-Segmente zum Indizieren. Kleinere Segmente werden im Laufe der Zeit zu größeren zusammengeführt. Dieser Prozess kann speicherintensiv sein. Obwohl Elasticsearch die Zusammenführung automatisch handhabt, kann es hilfreich sein, die Auswirkungen zu verstehen, insbesondere bei hoher Indizierungslast.

Such- und Aggregationsoptimierung

Keyword-Felder für Aggregationen verwenden: Aggregieren und sortieren Sie auf keyword, numerischen, Datums- oder anderen Feldern mit Doc-Values. Vermeiden Sie die Aktivierung von fielddata auf großen text-Feldern, es sei denn, Sie verstehen die Heap-Kosten.
Teure Abfragen einschränken: Führende Wildcard- und breite reguläre Ausdrucksabfragen können kostspielig sein. Bevorzugen Sie strukturierte Felder, Präfixe, N-Gramme oder Search-as-you-type-Mappings, wenn der Anwendungsfall eine teilweise Übereinstimmung erfordert.
Langsame Suchen profilieren: Verwenden Sie die Profil-API in einer Staging-Umgebung, um die Abfrageklauseln zu finden, die die meiste Arbeit verursachen.

Caches gezielt einsetzen

Elasticsearch verfügt über mehrere Caches. Sie helfen bei wiederholten Arbeiten, verbrauchen aber auch Speicher.

Shard-Request-Cache: Zwischenspeichert Suchergebnisse auf Shard-Ebene für berechtigte Anfragen, oft nützlich für wiederholte aggregationsartige Abfragen auf weitgehend unveränderten Daten. Seine Größe wird gesteuert mit:
```
indices.requests.cache.size: 5%
```
Dieses Beispiel setzt die Größe des Shard-Request-Caches auf 5% des Heaps.
Node-Query-Cache: Zwischenspeichert Filterkontextergebnisse. Seine Größe wird separat gesteuert:
```
indices.queries.cache.size: 10%
```
Fielddata-Cache: Verbraucht Heap und kann schnell wachsen, wenn Sie fielddata auf Textfeldern aktivieren. Bevorzugen Sie die korrekte Zuordnung von Feldern, anstatt sich auf einen größeren Fielddata-Cache zu verlassen.

OutOfMemory-Fehler verhindern

OutOfMemory-Fehler sind normalerweise das Endergebnis von anhaltendem Druck. Die Lösung ist selten "jede Grenze erhöhen".

Garbage Collection als Symptom behandeln

Aktuelle Elasticsearch-Versionen wählen unterstützte JVM-Standardeinstellungen für Sie aus. Vermeiden Sie benutzerdefinierte Garbage-Collector-Optimierungen, es sei denn, Sie haben versionsspezifische Anleitungen und Messungen. Lange Pausen deuten normalerweise auf Oversharding, teure Aggregationen, Fielddata, zu viel Heap-Druck oder unzureichende Knoten hin.

Wichtige Indikatoren für GC-Probleme sind:

Hohe GC-Zeit.
Lange Stop-the-World-Pausen.
Heap-Nutzung, die nach jeder Sammlung wieder nahe an die Grenze steigt.
OOM-Fehler bei großen Suchen, Bulk-Indizierung oder Aggregationen.

Schutzschalter respektieren

Schutzschalter schätzen die Speichernutzung und lehnen Operationen ab, bevor sie den Knoten erschöpfen können.

Fielddata-Schutzschalter: Begrenzt den Heap, der für Fielddata verwendet wird.
Request-Schutzschalter: Begrenzt den Speicher, der zum Abschließen von Anfragedatenstrukturen verwendet wird.
Parent-Schutzschalter: Verfolgt kombinierte Schutzschaltschätzungen.

Zeigen Sie Schutzschalter-Statistiken an mit:

curl -X GET "localhost:9200/_nodes/stats/breaker?pretty"

Sie können einige Schutzschaltereinstellungen über Cluster-Einstellungen ändern, aber tun Sie dies nur, nachdem Sie wissen, warum der Schutzschalter auslöst. Ein ausgelöster Schutzschalter schützt den Knoten oft vor einem OOM.

Überwachen und alarmieren

Alarmieren Sie bei:

JVM-Heap-Nutzung nach der Garbage Collection.
Garbage-Collection-Zeit und langen Pausen.
Schutzschalterauslösungen.
Indizierungsdruck und abgelehnten Thread-Pool-Aufgaben.
OS-Speicherdruck und Swap-Nutzung.
Shard-Anzahl pro Knoten und ungewöhnlich großen Aggregationen.

Fazit

Beginnen Sie mit der Heap-Größenanpassung, dann betrachten Sie die Shard-Anzahl, Feldzuordnungen, große Aggregationen und wiederholte Schutzschalterauslösungen. Wenn Ihr Knoten nach der Bereinigung immer noch unter Druck steht, fügen Sie Kapazität hinzu oder teilen Sie Arbeitslasten auf, anstatt die Warnsignale mit größeren Grenzen zu verstecken.