Skip to content

Commit e310d0a

Browse files
This documents the new threadpool-based merge scheduler, which is disk space aware, and blocks merges when disk space is low. The code changes were mostly introduced in #120869 and #127613 . (#130530)
1 parent ac321a6 commit e310d0a

File tree

2 files changed

+34
-17
lines changed

2 files changed

+34
-17
lines changed

docs/reference/index-modules/merge.asciidoc

Lines changed: 28 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -14,18 +14,32 @@ resources between merging and other activities like search.
1414
[[merge-scheduling]]
1515
=== Merge scheduling
1616

17-
The merge scheduler (ConcurrentMergeScheduler) controls the execution of merge
18-
operations when they are needed. Merges run in separate threads, and when the
19-
maximum number of threads is reached, further merges will wait until a merge
20-
thread becomes available.
21-
22-
The merge scheduler supports the following _dynamic_ setting:
23-
24-
`index.merge.scheduler.max_thread_count`::
25-
26-
The maximum number of threads on a single shard that may be merging at once.
27-
Defaults to
28-
`Math.max(1, Math.min(4, <<node.processors, node.processors>> / 2))` which
29-
works well for a good solid-state-disk (SSD). If your index is on spinning
30-
platter drives instead, decrease this to 1.
17+
The merge scheduler controls the execution of merge operations when they are needed.
18+
Merges run on the dedicated `merge` thread pool.
19+
Smaller merges are prioritized over larger ones, across all shards on the node.
20+
Merges are disk IO throttled so that bursts, while merging activity is otherwise low, are smoothed out in order to not impact indexing throughput.
21+
There is no limit on the number of merges that can be enqueued for execution on the thread pool.
22+
However, beyond a certain per-shard limit, after merging is completely disk IO un-throttled, indexing for the shard will itself be throttled until merging catches up.
23+
24+
The available disk space is periodically monitored, such that no new merge tasks are scheduled for execution when the available disk space is low.
25+
This is in order to prevent that the temporary disk space, which is required while merges are executed, completely fills up the disk space on the node.
26+
27+
The merge scheduler supports the following *dynamic* settings:
28+
29+
`index.merge.scheduler.max_thread_count`
30+
: The maximum number of threads on a **single** shard that may be merging at once. Defaults to `Math.max(1, Math.min(4, <<node.processors, node.processors>> / 2))` which works well for a good solid-state-disk (SSD). If your index is on spinning platter drives instead, decrease this to 1.
31+
32+
`indices.merge.disk.check_interval`
33+
: The time interval for checking the available disk space. Defaults to `5s`.
34+
35+
`indices.merge.disk.watermark.high`
36+
: Controls the disk usage watermark, which defaults to `95%`, beyond which no merge tasks can start execution.
37+
The disk usage tally includes the estimated temporary disk space still required by all the currently executing merge tasks.
38+
Any merge task scheduled *before* the limit is reached continues execution, even if the limit is exceeded while executing
39+
(merge tasks are not aborted).
40+
41+
`indices.merge.disk.watermark.high.max_headroom`
42+
: Controls the max headroom for the merge disk usage watermark, in case it is specified as percentage or ratio values.
43+
Defaults to `100GB` when `indices.merge.disk.watermark.high` is not explicitly set.
44+
This caps the amount of free disk space before merge scheduling is blocked.
3145

docs/reference/modules/threadpool.asciidoc

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -79,10 +79,13 @@ There are several thread pools, but the important ones include:
7979
default maximum size of `min(5, (`<<node.processors,
8080
`# of allocated processors`>>`) / 2)`.
8181

82+
`merge`::
83+
For [merge](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-merge.html) operations of all the shards on the node.
84+
Thread pool type is `scaling` with a keep-alive of `5m` and a default maximum size of [`# of allocated processors`](#node.processors).
85+
8286
`force_merge`::
83-
For <<indices-forcemerge,force merge>> operations.
84-
Thread pool type is `fixed` with a size of `max(1, (`<<node.processors,
85-
`# of allocated processors`>>`) / 8)` and an unbounded queue size.
87+
For waiting on blocking [force merge](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-forcemerge) operations.
88+
Thread pool type is `fixed` with a size of `max(1, (`[`# of allocated processors`](#node.processors)`) / 8)` and an unbounded queue size.
8689

8790
`management`::
8891
For cluster management.

0 commit comments

Comments
 (0)