Machine learning settings in Elasticsearch
editMachine learning settings in Elasticsearch
editYou do not need to configure any settings to use machine learning. It is enabled by default.
Machine learning uses SSE4.2 instructions, so it works only on machines whose
CPUs support SSE4.2. If you run Elasticsearch on older
hardware, you must disable machine learning (by setting xpack.ml.enabled
to false
).
General machine learning settings
edit-
node.roles: [ ml ]
-
(Static) Set
node.roles
to containml
to identify the node as a machine learning node. If you want to run machine learning jobs, there must be at least one machine learning node in your cluster.If you set
node.roles
, you must explicitly specify all the required roles for the node. To learn more, refer to Node.-
On dedicated coordinating nodes or dedicated master nodes, do not set
the
ml
role. -
It is strongly recommended that dedicated machine learning nodes also have the
remote_cluster_client
role; otherwise, cross-cluster search fails when used in machine learning jobs or datafeeds. See Remote-eligible node.
-
On dedicated coordinating nodes or dedicated master nodes, do not set
the
-
xpack.ml.enabled
-
(Static) The default value (
true
) enables machine learning APIs on the node.If you want to use machine learning features in your cluster, it is recommended that you use the default value for this setting on all nodes.
If set to
false
, the machine learning APIs are disabled on the node. For example, the node cannot open jobs, start datafeeds, receive transport (internal) communication requests, or requests from clients (including Kibana) related to machine learning APIs. -
xpack.ml.inference_model.cache_size
-
(Static) The maximum inference cache size allowed.
The inference cache exists in the JVM heap on each ingest node. The cache
affords faster processing times for the
inference
processor. The value can be a static byte sized value (such as2gb
) or a percentage of total allocated heap. Defaults to40%
. See also Machine learning circuit breaker settings.
-
xpack.ml.inference_model.time_to_live
-
(Static) The time to live (TTL) for trained models in
the inference model cache. The TTL is calculated from last access. Users of the
cache (such as the inference processor or inference aggregator) cache a model on
its first use and reset the TTL on every use. If a cached model is not accessed
for the duration of the TTL, it is flagged for eviction from the cache. If a
document is processed later, the model is again loaded into the cache. To update
this setting in Elasticsearch Service, see
Add Elasticsearch user settings. Defaults to
5m
. -
xpack.ml.max_inference_processors
-
(Dynamic) The total number of
inference
type processors allowed across all ingest pipelines. Once the limit is reached, adding aninference
processor to a pipeline is disallowed. Defaults to50
. -
xpack.ml.max_machine_memory_percent
-
(Dynamic) The maximum percentage of the machine’s memory that machine learning may use for running analytics processes. These processes are separate to the Elasticsearch JVM. The limit is based on the total memory of the machine, not current free memory. Jobs are not allocated to a node if doing so would cause the estimated memory use of machine learning jobs to exceed the limit. When the operator privileges feature is enabled, this setting can be updated only by operator users. The minimum value is
5
; the maximum value is200
. Defaults to30
.Do not configure this setting to a value higher than the amount of memory left over after running the Elasticsearch JVM unless you have enough swap space to accommodate it and have determined this is an appropriate configuration for a specialist use case. The maximum setting value is for the special case where it has been determined that using swap space for machine learning jobs is acceptable. The general best practice is to not use swap on Elasticsearch nodes.
-
xpack.ml.max_model_memory_limit
-
(Dynamic) The maximum
model_memory_limit
property value that can be set for any machine learning jobs in this cluster. If you try to create a job with amodel_memory_limit
property value that is greater than this setting value, an error occurs. Existing jobs are not affected when you update this setting. If this setting is0
or unset, there is no maximummodel_memory_limit
value. If there are no nodes that meet the memory requirements for a job, this lack of a maximum memory limit means it’s possible to create jobs that cannot be assigned to any available nodes. For more information about themodel_memory_limit
property, see Create anomaly detection jobs or Create data frame analytics jobs. Defaults to0
.
-
xpack.ml.max_open_jobs
-
(Dynamic) The maximum number of jobs that can run
simultaneously on a node. In this context, jobs include both anomaly detection jobs and
data frame analytics jobs. The maximum number of jobs is also constrained by memory
usage. Thus if the estimated memory usage of the jobs would be higher than
allowed, fewer jobs will run on a node. Prior to version 7.1, this setting was a
per-node non-dynamic setting. It became a cluster-wide dynamic setting in
version 7.1. As a result, changes to its value after node startup are used only
after every node in the cluster is running version 7.1 or higher. The minimum
value is
1
; the maximum value is512
. Defaults to512
. -
xpack.ml.nightly_maintenance_requests_per_second
-
(Dynamic) The rate at which the nightly maintenance
task deletes expired model snapshots and results. The setting is a proxy to the
requests_per_second
parameter used in the delete by query requests and controls throttling. When the operator privileges feature is enabled, this setting can be updated only by operator users. Valid values must be greater than0.0
or equal to-1.0
, where-1.0
means a default value is used. Defaults to-1.0
-
xpack.ml.node_concurrent_job_allocations
-
(Dynamic) The maximum number of jobs that can
concurrently be in the
opening
state on each node. Typically, jobs spend a small amount of time in this state before they move toopen
state. Jobs that must restore large models when they are opening spend more time in theopening
state. When the operator privileges feature is enabled, this setting can be updated only by operator users. Defaults to2
.
Advanced machine learning settings
editThese settings are for advanced use cases; the default values are generally sufficient:
-
xpack.ml.enable_config_migration
- (Dynamic) Reserved. When the operator privileges feature is enabled, this setting can be updated only by operator users.
-
xpack.ml.max_anomaly_records
-
(Dynamic) The maximum number of records that are
output per bucket. Defaults to
500
. -
xpack.ml.max_lazy_ml_nodes
-
(Dynamic) The number of lazily spun up machine learning nodes. Useful in situations where machine learning nodes are not desired until the first machine learning job opens. If the current number of machine learning nodes is greater than or equal to this setting, it is assumed that there are no more lazy nodes available as the desired number of nodes have already been provisioned. If a job is opened and this setting has a value greater than zero and there are no nodes that can accept the job, the job stays in the
OPENING
state until a new machine learning node is added to the cluster and the job is assigned to run on that node. When the operator privileges feature is enabled, this setting can be updated only by operator users. Defaults to0
.This setting assumes some external process is capable of adding machine learning nodes to the cluster. This setting is only useful when used in conjunction with such an external process.
-
xpack.ml.max_ml_node_size
-
(Dynamic)
The maximum node size for machine learning nodes in a deployment that supports automatic
cluster scaling. If you set it to the maximum possible size of future machine learning nodes,
when a machine learning job is assigned to a lazy node it can check (and fail quickly) when
scaling cannot support the size of the job. When the operator privileges feature is
enabled, this setting can be updated only by operator users. Defaults to
0b
, which means it will be assumed that automatic cluster scaling can add arbitrarily large nodes to the cluster. -
xpack.ml.persist_results_max_retries
-
(Dynamic) The maximum number of times to retry bulk
indexing requests that fail while processing machine learning results. If the limit is
reached, the machine learning job stops processing data and its status is
failed
. When the operator privileges feature is enabled, this setting can be updated only by operator users. The minimum value is0
; the maximum value is50
. Defaults to20
. -
xpack.ml.process_connect_timeout
-
(Dynamic) The connection timeout for machine learning processes
that run separately from the Elasticsearch JVM. When such processes are started they must
connect to the Elasticsearch JVM. If the process does not connect within the time period
specified by this setting then the process is assumed to have failed. When the
operator privileges feature is enabled, this setting can be updated only by operator
users. The minimum value is
5s
. Defaults to10s
. -
xpack.ml.use_auto_machine_memory_percent
-
(Dynamic) If this setting is
true
, thexpack.ml.max_machine_memory_percent
setting is ignored. Instead, the maximum percentage of the machine’s memory that can be used for running machine learning analytics processes is calculated automatically and takes into account the total node size and the size of the JVM on the node. When the operator privileges feature is enabled, this setting can be updated only by operator users. The default value isfalse
.- If you do not have dedicated machine learning nodes (that is to say, the node has multiple roles), do not enable this setting. Its calculations assume that machine learning analytics are the main purpose of the node.
-
The calculation assumes that dedicated machine learning nodes have at least
256MB
memory reserved outside of the JVM. If you have tiny machine learning nodes in your cluster, you shouldn’t use this setting.
Machine learning circuit breaker settings
edit-
breaker.model_inference.limit
-
(Dynamic) The limit for the trained model circuit
breaker. This value is defined as a percentage of the JVM heap. Defaults to
50%
. If the parent circuit breaker is set to a value less than50%
, this setting uses that value as its default instead. -
breaker.model_inference.overhead
-
(Dynamic) A constant that all trained model
estimations are multiplied by to determine a final estimation. See
Circuit breaker settings. Defaults to
1
. -
breaker.model_inference.type
-
(Static) The underlying type of the circuit breaker.
There are two valid options:
noop
andmemory
.noop
means the circuit breaker does nothing to prevent too much memory usage.memory
means the circuit breaker tracks the memory used by trained models and can potentially break and preventOutOfMemory
errors. The default value ismemory
.