Falling back to allocating job by job counts because a memory requirement refresh could not be scheduled - Elasticsearch Log Diagnostic

Get an Elasticsearch Check-Up

Check if your ES issues are caused from misconfigured settings
(Free 2 min process)

Check

Opster has analyzed this log so you don’t have to
Navigate directly to one of the sections in this page :

Troubleshooting Background – start here to get the full picture
Log Context – usefull for experts
Related Issues – selected resources from the community
About Opster – offering a diffrent approach to troubleshoot Elasticsearch

Check My Elasticsearch

Troubleshooting background

To troubleshoot Elasticsearch log “Falling back to allocating job by job counts because a memory requirement refresh could not be scheduled” it’s important to know common problems related to Elasticsearch concepts: memory, plugin, refresh. See below-detailed explanations complete with common problems, examples and useful tips.

Memory in Elasticsearch

What is it

Memory is one of the most critical resources to monitor in Elasticsearch. Elasticsearch runs on JVM and uses heap memory areas for query cache, request cache, accessing lucene segments and storing fielddata for aggregations and sorting.

Commos problems and important points

The most common error that arises in Elasticsearch is OutOfMemory error. This error comes when the node is not able to cope up with the required heap size space. To avoid this, you need to closely monitor the heap utilization and garbage collector performance.
As per the most up-to-date best practices you should not allocate more than 50 percent of total RAM to JVM heap size. Starting from Elasticsearch version 5.x onward this can be set using -Xms and -Xmx parameters inside jvm.options configuration file. The defaults are set to 1 GB for both minimum and maximum heap size.
The heap size should not set more than 31 GB in any case to avoid the poor garbage collection.

Plugin in Elasticsearch

What it is

Plugins are used to extend the functionality of Elasticsearch. In addition to the core plugins available to you, it is possible to write custom plugins as well. Plugins are generated in a zip format with the mandatory file structure.

Examples:

Core Plugins: Xpack for Security and monitoring, Discovery plugins for EC2
Adding S3 plugin for storing snapshots on S3

sudo bin/elasticsearch-plugin install repository-s3

Adding HDFS plugin for storing snapshots on HDFS

sudo bin/elasticsearch-plugin install repository-hdfs

Removing a plugin

sudo bin/elasticsearch-plugin remove repository-hdfs

Notes:

Plugins are installed using the Elasticsearch-plugin script, which enables actions such as listing, removing and installing plugins.
Core plugins can be installed simply by providing the name of the plugin to the Elasticsearch-plugin command.
You can also download the plugin manually and then install it using the elasticsearch-plugin install command, providing the file name/path of the plugin’s source file.
When a plugin is removed, you will need to restart the elasticsearch node(s) in order to complete the removal process.

Common Problems:

You need to install the required plugins in your Elasticsearch deployment before moving it to production machines. (as it’s likely your production machines are behind a proxy and it’s very hard to get plugins installed behind a proxy).

The same is true when you are going to deploy elasticsearch using Docker images, you will most likely be rebuilding the standard image and including your required plugins in the custom docker build. Make sure the docker build is run on a build machine that is not behind a proxy, otherwise the plugin installation will fail during docker build.

Click here to get to our list of the Most frequent issues caused by Elasticsearch Plugins

Log Context

Log ”Falling back to allocating job by job counts because a memory requirement refresh could not be scheduled” classname is TransportOpenJobAction.java
To help get the right context about this log, we have extracted the following from Elasticsearch source code

<pre class="wp-block-syntaxhighlighter-code"> 
        // Try to allocate jobs according to memory usage; but if that's not possible (maybe due to a mixed version cluster or maybe
        // because of some weird OS problem) then fall back to the old mechanism of only considering numbers of assigned jobs
        boolean allocateByMemory = isMemoryTrackerRecentlyRefreshed;
        if (isMemoryTrackerRecentlyRefreshed == false) {
            logger.warn("Falling back to allocating job [{}] by job counts because a memory requirement refresh could not be scheduled";
                jobId);
        }

        List<String> reasons = new LinkedList<>();
        long maxAvailableCount = Long.MIN_VALUE;




</pre>

To help troubleshoot related issues we have gathered selected answers from STOF & Discuss and issues from Github, please review the following for further information :

Ven Failed To Execute Goal Org Apac
stackoverflow.com/questions/20442862/maven-failed-to-execute-goal-org-apache-maven-pluginsmaven-clean-plugin2-4-1

Github Issue Number 12366
github.com/elastic/elasticsearch/issues/12366

About Opster

Incorporating deep knowledge and broad history of Elasticsearch issues. Opster’s solution identifies and predicts root causes of Elasticsearch problems, provides recommendations and can automatically perform various actions to manage, troubleshoot and prevent issues

We are constantly updating our analysis of Elasticsearch logs, errors, and exceptions. Sharing best practices and providing troubleshooting guides.

Learn more: Glossary | Blog| Troubleshooting guides | Error Repository

Need help with any Elasticsearch issue ? Contact Opster

Falling back to allocating job by job counts because a memory requirement refresh could not be scheduled – Elasticsearch Log Diagnostic