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. Take a self-guided product tour to see for yourself (no registration required).

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

 

Watch product tour

Try AutoOps to find & fix Elasticsearch problems

Analyze Your Cluster
Skip to content