Ignoring index.merge.scheduler.max_merge_at_once . because we are using ConcurrentMergeScheduler(2. 1) – How to solve related issues

Opster Team

Feb-20, Version: 1.7-8.0

Before you begin reading this guide, we recommend you run Elasticsearch Error Check-Up which analyzes 2 JSON files to detect many errors.

To easily locate the root cause and resolve this issue try AutoOps for Elasticsearch & OpenSearch. It diagnoses problems by analyzing hundreds of metrics collected by a lightweight agent and offers guidance for resolving them.

This guide will help you check for common problems that cause the log ” Ignoring index.merge.scheduler.max_merge_at_once . because we are using ConcurrentMergeScheduler(2. 1) ” to appear. To understand the issues related to this log, read the explanation below about the following Elasticsearch concepts: index and merge.

Log Context

Log “ignoring index.merge.scheduler.max_merge_at_once [{}]; because we are using ConcurrentMergeScheduler(2; 1)” classname is SerialMergeSchedulerProvider.java.
We extracted the following from Elasticsearch source code for those seeking an in-depth context :

     
Inject
    public SerialMergeSchedulerProvider(ShardId shardId; 
IndexSettings Settings indexSettings; ThreadPool threadPool) {
        super(shardId; indexSettings; threadPool);
        Integer value = componentSettings.getAsInt("max_merge_at_once"; null);
        if (value != null) {
            logger.warn("ignoring index.merge.scheduler.max_merge_at_once [{}]; because we are using ConcurrentMergeScheduler(2; 1)"; value);
        }
        logger.trace("using [concurrent] merge scheduler; max_thread_count=1; max_merge_count=2");
    }

    
Override

 

How helpful was this guide?

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?

Analyze your cluster & get personalized recommendations

Skip to content