Switch back to ConcurrentMergeScheduler
Load tests showed that SerialMS has problems to keep up with the merges under high load. We should switch back to CMS until we have a better story to balance merge threads / efforts across shards on a single node. Closes #5817
This commit is contained in:
parent
9920084ba2
commit
320a206352
|
@ -187,11 +187,7 @@ Defaults to unbounded.
|
|||
|
||||
The merge schedule controls the execution of merge operations once they
|
||||
are needed (according to the merge policy). The following types are
|
||||
supported, with the default being the `SerialMergeScheduler`.
|
||||
|
||||
Note, the default is the serial merge scheduler since there is a merge
|
||||
thread pool that explicitly schedules merges, and it makes sure that
|
||||
merges are serial within a shard, yet concurrent across multiple shards.
|
||||
supported, with the default being the `ConcurrentMergeScheduler`.
|
||||
|
||||
[float]
|
||||
==== ConcurrentMergeScheduler
|
||||
|
|
|
@ -28,7 +28,7 @@ import org.elasticsearch.common.settings.Settings;
|
|||
public class MergeSchedulerModule extends AbstractModule {
|
||||
|
||||
public static final String MERGE_SCHEDULER_TYPE_KEY = "index.merge.scheduler.type";
|
||||
public static final Class<? extends MergeSchedulerProvider> DEFAULT = SerialMergeSchedulerProvider.class;
|
||||
public static final Class<? extends MergeSchedulerProvider> DEFAULT = ConcurrentMergeSchedulerProvider.class;
|
||||
|
||||
private final Settings settings;
|
||||
|
||||
|
|
Loading…
Reference in New Issue