Force Merge und Segment-Optimierung richtig einsetzen

1. Wie Lucene-Segmente durch fortlaufende Indexierung entstehen

Jeder Elasticsearch-Index besteht intern aus einem oder mehreren Shards, und jeder Shard wiederum aus einer Sammlung unveränderlicher Lucene-Segmente. Bei jedem Refresh-Zyklus schreibt Lucene die zwischenzeitlich indexierten Dokumente als neues, eigenständiges Segment auf die Festplatte, statt bestehende Segmente zu verändern. Diese Unveränderlichkeit ist bewusst gewählt, da sie parallele Lesezugriffe ohne aufwendige Sperrmechanismen ermöglicht und die Grundlage für Lucenes hohe Indexierungsgeschwindigkeit bildet.

Bei kontinuierlicher Indexierung entstehen dadurch fortlaufend neue, oft sehr kleine Segmente. Ein Hintergrundprozess, die Merge Policy, fasst kleinere Segmente automatisch zu größeren zusammen, sobald bestimmte Schwellenwerte erreicht sind, wodurch die Segmentanzahl in einem gesunden Gleichgewicht bleibt. Bei sehr hoher Schreiblast oder ungünstig konfigurierten Merge-Schwellenwerten kann die automatische Verdichtung mit der Neuentstehung von Segmenten allerdings nicht immer Schritt halten, wodurch sich über Zeit spürbar mehr Segmente ansammeln als eigentlich nötig wären.

2. Warum fragmentierte Segmente Abfrage-Performance kosten

Eine Abfrage gegen einen Lucene-Shard muss grundsätzlich jedes einzelne Segment durchsuchen und die Teilergebnisse anschließend zusammenführen. Mit jedem zusätzlichen Segment steigt der Verwaltungsaufwand: mehr Dateideskriptoren, mehr Suchaufrufe pro Abfrage und mehr Aufwand beim Zusammenführen der Teilergebnisse zu einem finalen, sortierten Ergebnis. Bei einem Shard mit wenigen, großen Segmenten ist dieser Overhead gering, bei einem Shard mit hunderten kleiner Segmente kann er spürbar ins Gewicht fallen.

Besonders deutlich zeigt sich der Effekt bei Aggregationen und Sortierungen über große Dokumentmengen, da hier jedes Segment einzeln durchlaufen werden muss, bevor die globalen Ergebnisse zusammengeführt werden können. Ein Index mit stark fragmentierten Segmenten kann bei identischer Dokumentanzahl deutlich langsamer antworten als ein verdichteter Index, was in der Praxis häufig fälschlicherweise als generelles Performance-Problem statt als konkretes Segment-Problem diagnostiziert wird.

3. Was Force Merge technisch bewirkt: das max_num_segments-Ziel

Force Merge stößt manuell genau den Verdichtungsprozess an, der normalerweise automatisch im Hintergrund läuft, erzwingt dabei aber ein konkretes Zielergebnis über den Parameter max_num_segments. Wird dieser Wert etwa auf eins gesetzt, verschmilzt Elasticsearch alle Segmente eines Shards zu einem einzigen, physisch zusammenhängenden Segment. Das reduziert den Verwaltungsoverhead bei künftigen Abfragen auf ein Minimum, da nur noch ein einziges Segment durchsucht werden muss.

Technisch bedeutet dieser Prozess, dass Lucene alle relevanten Segmente komplett neu liest, gelöschte Dokumente dabei endgültig entfernt und das Ergebnis als neues Segment auf die Festplatte schreibt. Das erklärt sowohl den Nutzen, ein sauber verdichteter Index benötigt weniger Speicherplatz und liefert schnellere Abfragen, als auch die Kosten dieses Vorgangs, denn während der Ausführung müssen kurzzeitig sowohl die alten als auch die neuen Segmentdaten gleichzeitig auf der Festplatte vorhanden sein.

POST produktkatalog-2026.07/_forcemerge?max_num_segments=1

4. Wann ein manueller Force Merge sinnvoll ist: nur abgeschlossene Indizes

Force Merge ergibt fast ausschließlich bei Indizes Sinn, die endgültig nicht mehr beschrieben werden, typischerweise nach einem Rollover, wenn ein zeitbasierter Index seinen aktiven Lebensabschnitt beendet hat. Klassische Beispiele sind ein abgeschlossener Monats-Index für Log-Daten, ein archivierter Bestellungs-Index nach Geschäftsjahresende oder ein Snapshot-Vorbereitungsschritt, bei dem ein verdichteter Index deutlich kompaktere und schneller zu erstellende Snapshots ermöglicht.

Der entscheidende Grund für diese Einschränkung liegt darin, dass ein Force Merge auf einem weiterhin beschriebenen Index sofort wieder neue, kleine Segmente erzeugt, sobald die nächsten Dokumente ankommen. Der mühsam erzielte Verdichtungseffekt wäre also binnen kürzester Zeit wieder verpufft, während die Kosten des Vorgangs, insbesondere die I/O-Last, in vollem Umfang angefallen wären. Genau deshalb ist die Kombination aus Rollover und anschließendem Force Merge in der Warm-Phase einer ILM-Richtlinie so verbreitet.

5. Risiken bei falscher Anwendung: I/O-Spitzen auf aktiven Indizes

Wird Force Merge versehentlich auf einem aktiv beschriebenen, produktiven Index ausgeführt, entsteht typischerweise eine massive I/O-Spitze: Das komplette Neuschreiben großer Segmentmengen konkurriert direkt mit den laufenden Schreibvorgängen um Festplattenbandbreite, was die Indexierungsrate spürbar senken und gleichzeitig die Latenz gleichzeitiger Leseabfragen erhöhen kann. Bei stark ausgelasteten Produktionsclustern kann eine unüberlegte Force-Merge-Ausführung im schlimmsten Fall zu spürbaren Timeouts bei Nutzeranfragen führen.

Ein weiteres, oft unterschätztes Risiko ist der temporäre Speicherplatzbedarf: Während des Merge-Vorgangs müssen sowohl die Quellsegmente als auch das neu entstehende Zielsegment gleichzeitig auf der Festplatte Platz finden, was kurzzeitig deutlich mehr freien Speicherplatz erfordert als der Index im Ruhezustand belegt. Ein Cluster mit knappem Festplattenspeicher kann durch einen unbedacht gestarteten Force Merge in einen kritischen Speicherengpass geraten, der im schlimmsten Fall weitere Schreibvorgänge im gesamten Cluster blockiert.

6. Force Merge im ILM-Kontext als automatisierte Warm-Phase-Aktion

In einer gut konfigurierten ILM-Richtlinie taucht Force Merge fast nie als manuell ausgeführter Befehl auf, sondern als deklarative Aktion in der Warm-Phase, die erst nach der garantierten Mindestdauer seit dem Rollover greift. Da ILM zu diesem Zeitpunkt bereits sicherstellt, dass der Index nicht mehr der aktuelle Schreibziel-Index ist, entfällt das Risiko einer versehentlichen Anwendung auf einen noch aktiven Index vollständig, sofern die Richtlinie korrekt mit dem Rollover-Alias verknüpft ist.

Dennoch lohnt sich eine bewusste Priorisierung innerhalb der Cluster-Ressourcen: Ein Force Merge, der zeitgleich mit vielen anderen ILM-Übergängen auf mehreren Indizes gleichzeitig läuft, kann trotz korrekter Anwendung auf abgeschlossene Indizes die verfügbare I/O-Bandbreite des gesamten Clusters kurzfristig stark beanspruchen, weshalb eine gestaffelte Ausführung über den Tag verteilt in vielen Setups sinnvoller ist als eine Konzentration auf ein enges Zeitfenster.

7. Force Merge und expunge_deletes: der wichtige Unterschied

Neben dem vollständigen Force Merge mit festem max_num_segments-Ziel gibt es die deutlich schonendere Option only_expunge_deletes, die ausschließlich Segmente mit einem hohen Anteil an bereits gelöschten, aber physisch noch vorhandenen Dokumenten bereinigt, ohne die Gesamtzahl der Segmente auf einen festen Zielwert zu reduzieren. Das ist besonders relevant für Indizes mit häufigen Updates, bei denen Elasticsearch alte Dokumentversionen intern als gelöscht markiert, aber erst beim nächsten Merge tatsächlich physisch entfernt.

Diese gezielte Bereinigung ist deutlich ressourcenschonender als ein vollständiger Force Merge, da nur Segmente mit einem hohen Löschanteil überhaupt angefasst werden, statt jedes Segment unabhängig vom Zustand neu zu schreiben. Für Indizes, die zwar weiterhin gelegentlich aktualisiert, aber nicht mehr mit hoher Frequenz beschrieben werden, ist only_expunge_deletes deshalb häufig die bessere Wahl gegenüber einem vollständigen Force Merge auf eine feste Segmentanzahl.

curl -X POST "localhost:9200/bewertungen-archiv/_forcemerge?only_expunge_deletes=true"

8. Monitoring während Force Merge: Task API und Cluster Health

Ein Force Merge auf großen Indizes kann von wenigen Minuten bis zu mehreren Stunden dauern, weshalb der Fortschritt aktiv über die Task API verfolgt werden sollte, statt den Vorgang als Fire-and-Forget zu betrachten. Die Task API zeigt sowohl die aktuell laufende Aktion als auch, sofern gewünscht, eine Blockierung des Aufrufs, bis der Vorgang abgeschlossen ist, was sich für automatisierte Skripte anbietet, die erst nach vollständigem Abschluss weiterarbeiten sollen.

Parallel dazu lohnt sich eine Beobachtung der Cluster Health und insbesondere der Werte für Festplattennutzung und I/O-Auslastung während der Ausführung, um frühzeitig zu erkennen, ob der Vorgang unerwartet Ressourcen anderer, gleichzeitig laufender Operationen beeinträchtigt. Bei kritischen Produktionsumgebungen empfiehlt sich zusätzlich, Force-Merge-Läufe bewusst in Zeitfenster mit geringerer Gesamtlast zu legen, etwa nachts, statt sie während der Haupt-Geschäftszeiten anzustoßen.

9. Force Merge und Disk-Watermarks im Zusammenspiel

Der temporär erhöhte Speicherbedarf während eines Force Merge kann in Kombination mit den cluster-weiten Disk-Watermark-Schwellenwerten zu einem eigenen Problem werden. Überschreitet ein Knoten während des Merge-Vorgangs die konfigurierte High-Watermark-Schwelle, beginnt Elasticsearch, Shards von diesem Knoten wegzuverlagern, was zusätzliche Netzwerk- und I/O-Last erzeugt, genau während der Knoten ohnehin schon stark ausgelastet ist. Wird sogar die Flood-Stage-Schwelle erreicht, setzt Elasticsearch betroffene Indizes automatisch schreibgeschützt, was in einem produktiven Setup schwerwiegende Folgen haben kann.

Vor einem geplanten Force Merge lohnt sich deshalb eine kurze Prüfung des tatsächlich verfügbaren freien Speicherplatzes je Knoten im Verhältnis zur Größe der zu verschmelzenden Segmente. Bei knappen Kapazitäten ist ein moderater Zielwert wie max_num_segments=5 statt 1 ein sinnvoller Kompromiss, da er den temporären Speicherbedarf deutlich reduziert und trotzdem einen Großteil des Performance-Gewinns liefert, ohne den Knoten in die Nähe der kritischen Watermark-Schwellen zu bringen.

10. Zusammenfassung

11. FAQ: Force Merge in Elasticsearch: Das Wichtigste auf einen Blick