Why does the ILM forcemerge action belong in the warm phase rather than on a live write index?
answer
- Fewer segments, less per-search overhead
- Rewrites the whole index once
- One huge segment is never merged again
- Deletes inside it are never reclaimed
- Only safe when nothing writes any more
basics
~20 sForce merge rewrites an index into very few segments, which is expensive and only pays off once the data stops changing. A single huge segment is never merged again, so deleted documents inside it are never reclaimed while writes continue.
solid answer
~50 sThe `forcemerge` action rewrites an index down to `max_num_segments` segments, usually one. Fewer segments means less per-segment overhead at search time — fewer term dictionaries to consult, fewer files, less heap for segment metadata — and deleted documents are physically dropped during the rewrite. It is an expensive, IO- and CPU-heavy rewrite of the entire index, and it needs temporary disk headroom for the new segment while the old ones still exist. Worse, running it on an index that still takes writes is actively harmful: normal merging is tiered, and a single enormous segment will essentially never be selected for merging again. Every subsequent delete or update leaves a tombstone in it that is never reclaimed, so the index bloats permanently. That is why ILM places it after rollover — the index is immutable by then — and marks the index read-only for the merge.
code
json · 14 lines// PUT _ilm/policy/logs-13m (warm phase excerpt)
{
"warm": {
"min_age": "7d",
"actions": {
"readonly": {},
"forcemerge": {
"max_num_segments": 1,
"index_codec": "best_compression"
},
"set_priority": { "priority": 50 }
}
}
}go deeper
Recall what a force merge is for: combining many segments into few so searches touch less and deleted documents are finally removed from disk.
Explain the mechanics — immutable segments, deletes as tombstones reclaimed only by merging, and the tiered merge policy's size ceiling that leaves an oversized segment permanently unmerged.
Be ready to schedule it: the IO and disk-headroom cost, why it only belongs on indices that no longer take writes, and how a failed merge leaves the lifecycle policy stalled.
Own the trade across the fleet — which retention classes earn the merge at all, staggering transitions so hundreds of indices do not merge at once, and whether heavier compression is worth the read-time CPU.
## What force merge does An Elasticsearch index is a set of Lucene segments: immutable files produced by refreshes and by background merges. Search cost has a per-segment component, because each segment carries its own term dictionary, postings, doc values and metadata, and a query must visit each one. Updates and deletes do not modify segments; they mark a document as deleted in a live-docs bitset and write the new version elsewhere, so the old copy occupies disk until a merge rewrites the segment without it. The `forcemerge` action tells Lucene to merge down to a target number of segments, `max_num_segments`, most often `1`. Two things follow: search touches one segment instead of dozens, and every deleted document in the source segments disappears, reclaiming their disk space. In an ILM policy the action looks like `"forcemerge": { "max_num_segments": 1 }`, and it also accepts `index_codec: best_compression` to rewrite the data with heavier compression at the same time — a meaningful saving for log-shaped data that will be read rarely. ## Why it is expensive A force merge to one segment reads the entire index and writes it out again. On a 50 GB shard that is 50 GB of reads and 50 GB of writes, saturating disk and burning CPU on decompression and recompression, and it needs enough free disk to hold the new segment alongside the originals until the merge commits. On a busy cluster that competes directly with indexing and search for the same IO budget. It is the kind of operation you schedule, not the kind you sprinkle. ## Why a live index is the wrong target This is the part interviewers are actually probing. Lucene's default merge policy is tiered: it prefers merging segments of similar size, and it declines to consider segments above a maximum size for ordinary merging. A single 50 GB segment sits far above that ceiling, so it is effectively frozen — no routine merge will ever pick it up again. Now keep writing to that index. Every update and delete marks a document deleted inside that giant segment. Because the segment will never be re-merged in the normal course of events, those deletions are never reclaimed. Deleted-document ratio climbs, disk usage climbs, and search reads more data than it needs — permanently, until someone force merges again, which reintroduces the whole cost. So the rule is: force merge only what will never be written to again. In a data stream, that is precisely a backing index that has rolled over. ILM makes this explicit by marking the index read-only as part of the action, and by placing `forcemerge` in the warm phase (or in hot, but only after `rollover` has run). ## When it is worth it The benefit is proportional to how many segments there are and how long the index will be read afterwards. A backing index that will be queried for months and then archived is a good candidate: pay once, save on every query and on storage for the whole life of the index. A backing index that will be deleted in three days is not — the merge costs more than it will ever repay. Merging to exactly one segment is also not sacred. `max_num_segments: 1` maximises the search benefit but produces the largest possible immovable segment and the longest merge. Some operators target a small number rather than one, which retains most of the per-segment saving while keeping each segment within the range that ordinary merging can still handle. ## Ordering within a lifecycle A typical warm phase runs, in effect: make the index read-only, optionally shrink it to fewer shards, force merge it, and set a lower recovery priority so that recovering hot indices are restored first. Ordering matters conceptually — you shrink before merging so you merge fewer, larger shards once rather than merging then shrinking — and ILM applies the phase's actions in a fixed internal order rather than the order you happen to write them in the JSON. Force merge also pairs naturally with the cold phase's searchable snapshots: a well-merged index snapshots into fewer, larger blobs, which is cheaper to store and cheaper to fetch. ## Operating it safely A force merge started via ILM runs as a lifecycle step and is not something you can cancel with a single API call the way you would abort a query; it completes on its own schedule. Because it is IO-heavy, the usual mitigations are to stagger phase transitions across streams so many indices do not merge at once, and to keep the warm phase's `min_age` far enough back that the merge lands outside the ingest peak. Watch free disk on warm nodes: a merge that runs out of headroom fails and leaves the index in an ILM error step, which is one of the more common reasons a policy stalls.
- What does index_codec best_compression change, and what does it cost?It rewrites the stored fields with a heavier compression algorithm, cutting disk usage noticeably for log-shaped data. The cost is CPU on decompression whenever documents are fetched — so it suits data that is stored far more often than it is read, which is exactly what warm and cold indices are. Because it changes the codec, it applies to the segments the merge writes, not retroactively to untouched ones.
- Is merging to a single segment always the right target?No. One segment maximises the search saving but produces the largest possible segment, which sits above the size that ordinary tiered merging will ever reconsider, and takes the longest to produce. Targeting a small handful of segments keeps most of the per-segment saving while leaving each segment in a range normal merging can still manage, which is safer if there is any chance of future writes.
- An ILM force merge fails and the index sits in an error step. What is the usual cause?Insufficient free disk on the node holding the shard. A merge needs room for the new segment while the originals still exist, so a node close to a watermark cannot complete it. Free space or move the shard, then call the ILM retry API for that index; it resumes at the failed step rather than restarting the phase.
saying these in an interview costs you the question
- Runs force merge routinely on the active write index
- Thinks force merge is cheap because it only reorganises metadata
- Believes deleted documents are reclaimed without a merge
- Assumes one segment is always the correct target
- Forgets the temporary disk headroom a merge requires