Docs: explain that SerialMergeScheduler just maps to CMS for back compat
Closes #6878
This commit is contained in:
parent
56cfa8e47e
commit
63cab559e3
|
@ -201,18 +201,6 @@ spinning platter drives instead, decrease this to 1.
|
|||
[float]
|
||||
==== SerialMergeScheduler
|
||||
|
||||
A merge scheduler that simply does each merge sequentially using the
|
||||
calling thread (blocking the operations that triggered the merge or the
|
||||
index operation). This merge scheduler has a merge thread pool that
|
||||
explicitly schedules merges, and it makes sure that merges are serial
|
||||
within a shard, yet concurrent across multiple shards.
|
||||
|
||||
The scheduler supports the following settings:
|
||||
|
||||
`index.merge.scheduler.max_merge_at_once`::
|
||||
|
||||
The maximum number of merges a single merge run performs. This setting prevents
|
||||
executing unlimited amount of merges in a loop until another shards has a
|
||||
chance to get a merge thread from the pool. If this limit is reached the
|
||||
merge thread returns to the pool and continues once the the call to a single
|
||||
shards is executed. The default is `5`
|
||||
This is accepted for backwards compatibility, but just uses
|
||||
ConcurrentMergeScheduler with index.merge.scheduler.max_thread_count
|
||||
set to 1 so that only 1 merge may run at a time.
|
||||
|
|
Loading…
Reference in New Issue