mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-09 06:25:07 +00:00
9eeae59a83
The use of available processors, the terminology, and the settings around it have evolved over time. This commit cleans up some places in the codes and in the docs to adjust to the current terminology.
32 lines
1.2 KiB
Plaintext
32 lines
1.2 KiB
Plaintext
[[index-modules-merge]]
|
|
== Merge
|
|
|
|
A shard in Elasticsearch is a Lucene index, and a Lucene index is broken down
|
|
into segments. Segments are internal storage elements in the index where the
|
|
index data is stored, and are immutable. Smaller segments are periodically
|
|
merged into larger segments to keep the index size at bay and to expunge
|
|
deletes.
|
|
|
|
The merge process uses auto-throttling to balance the use of hardware
|
|
resources between merging and other activities like search.
|
|
|
|
[float]
|
|
[[merge-scheduling]]
|
|
=== Merge scheduling
|
|
|
|
The merge scheduler (ConcurrentMergeScheduler) controls the execution of merge
|
|
operations when they are needed. Merges run in separate threads, and when the
|
|
maximum number of threads is reached, further merges will wait until a merge
|
|
thread becomes available.
|
|
|
|
The merge scheduler supports the following _dynamic_ setting:
|
|
|
|
`index.merge.scheduler.max_thread_count`::
|
|
|
|
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.
|
|
|