mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-06 04:58:50 +00:00
558e323c89
This change introduces a new setting, xpack.ml.process_connect_timeout, to enable the timeout for one of the external ML processes to connect to the ES JVM to be increased. The timeout may need to be increased if many processes are being started simultaneously on the same machine. This is unlikely in clusters with many ML nodes, as we balance the processes across the ML nodes, but can happen in clusters with a single ML node and a high value for xpack.ml.node_concurrent_job_allocations.
120 lines
5.7 KiB
Plaintext
120 lines
5.7 KiB
Plaintext
|
|
[role="xpack"]
|
|
[[ml-settings]]
|
|
=== Machine learning settings in Elasticsearch
|
|
++++
|
|
<titleabbrev>Machine learning settings</titleabbrev>
|
|
++++
|
|
|
|
You do not need to configure any settings to use {ml}. It is enabled by default.
|
|
|
|
IMPORTANT: {ml-cap} uses SSE4.2 instructions, so will only work on machines whose
|
|
CPUs https://en.wikipedia.org/wiki/SSE4#Supporting_CPUs[support] SSE4.2. If you
|
|
run {es} on older hardware you must disable {ml} (by setting `xpack.ml.enabled`
|
|
to `false`).
|
|
|
|
All of these settings can be added to the `elasticsearch.yml` configuration file.
|
|
The dynamic settings can also be updated across a cluster with the
|
|
<<cluster-update-settings,cluster update settings API>>.
|
|
|
|
TIP: Dynamic settings take precedence over settings in the `elasticsearch.yml`
|
|
file.
|
|
|
|
[float]
|
|
[[general-ml-settings]]
|
|
==== General machine learning settings
|
|
|
|
`node.ml`::
|
|
Set to `true` (default) to identify the node as a _machine learning node_. +
|
|
+
|
|
If set to `false` in `elasticsearch.yml`, the node cannot run jobs. If set to
|
|
`true` but `xpack.ml.enabled` is set to `false`, the `node.ml` setting is
|
|
ignored and the node cannot run jobs. If you want to run jobs, there must be at
|
|
least one machine learning node in your cluster. +
|
|
+
|
|
IMPORTANT: On dedicated coordinating nodes or dedicated master nodes, disable
|
|
the `node.ml` role.
|
|
|
|
`xpack.ml.enabled`::
|
|
Set to `true` (default) to enable {ml} on the node. +
|
|
+
|
|
If set to `false` in `elasticsearch.yml`, the {ml} APIs are disabled on the node.
|
|
Therefore the node cannot open jobs, start {dfeeds}, or receive transport (internal)
|
|
communication requests related to {ml} APIs. It also affects all {kib} instances
|
|
that connect to this {es} instance; you do not need to disable {ml} in those
|
|
`kibana.yml` files. For more information about disabling {ml} in specific {kib}
|
|
instances, see
|
|
{kibana-ref}/ml-settings-kb.html[{kib} Machine Learning Settings].
|
|
+
|
|
IMPORTANT: If you want to use {ml} features in your cluster, you must have
|
|
`xpack.ml.enabled` set to `true` on all master-eligible nodes. This is the
|
|
default behavior.
|
|
|
|
`xpack.ml.max_machine_memory_percent` (<<cluster-update-settings,Dynamic>>)::
|
|
The maximum percentage of the machine's memory that {ml} may use for running
|
|
analytics processes. (These processes are separate to the {es} JVM.) Defaults to
|
|
`30` percent. The limit is based on the total memory of the machine, not current
|
|
free memory. Jobs will not be allocated to a node if doing so would cause the
|
|
estimated memory use of {ml} jobs to exceed the limit.
|
|
|
|
`xpack.ml.max_model_memory_limit` (<<cluster-update-settings,Dynamic>>)::
|
|
The maximum `model_memory_limit` property value that can be set for any job on
|
|
this node. If you try to create a job with a `model_memory_limit` property value
|
|
that is greater than this setting value, an error occurs. Existing jobs are not
|
|
affected when you update this setting. For more information about the
|
|
`model_memory_limit` property, see <<ml-apilimits>>.
|
|
|
|
`xpack.ml.max_open_jobs` (<<cluster-update-settings,Dynamic>>)::
|
|
The maximum number of jobs that can run simultaneously on a node. Defaults to
|
|
`20`. In this context, jobs include both anomaly detector 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 maximum permitted value is `512`.
|
|
|
|
`xpack.ml.node_concurrent_job_allocations` (<<cluster-update-settings,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 to `open` state. Jobs that must restore large models when they are
|
|
opening spend more time in the `opening` state. Defaults to `2`.
|
|
|
|
[float]
|
|
[[advanced-ml-settings]]
|
|
==== Advanced machine learning settings
|
|
|
|
These settings are for advanced use cases; the default values are generally
|
|
sufficient:
|
|
|
|
`xpack.ml.enable_config_migration` (<<cluster-update-settings,Dynamic>>)::
|
|
Reserved.
|
|
|
|
`xpack.ml.max_anomaly_records` (<<cluster-update-settings,Dynamic>>)::
|
|
The maximum number of records that are output per bucket. The default value is
|
|
`500`.
|
|
|
|
`xpack.ml.max_lazy_ml_nodes` (<<cluster-update-settings,Dynamic>>)::
|
|
The number of lazily spun up Machine Learning nodes. Useful in situations
|
|
where ML nodes are not desired until the first Machine Learning Job
|
|
is opened. It defaults to `0` and has a maximum acceptable value of `3`.
|
|
If the current number of ML nodes is `>=` than this setting, then it is
|
|
assumed that there are no more lazy nodes available as the desired number
|
|
of nodes have already been provisioned. When a job is opened with this
|
|
setting set at `>0` and there are no nodes that can accept the job, then
|
|
the job will stay in the `OPENING` state until a new ML node is added to the
|
|
cluster and the job is assigned to run on that node.
|
|
+
|
|
IMPORTANT: This setting assumes some external process is capable of adding ML nodes
|
|
to the cluster. This setting is only useful when used in conjunction with
|
|
such an external process.
|
|
|
|
`xpack.ml.process_connect_timeout` (<<cluster-update-settings,Dynamic>>)::
|
|
The connection timeout for {ml} processes that run separately from the {es} JVM.
|
|
Defaults to `10s`. Some {ml} processing is done by processes that run separately
|
|
to the {es} JVM. When such processes are started they must connect to the {es}
|
|
JVM. If such a process does not connect within the time period specified by this
|
|
setting then the process is assumed to have failed. Defaults to `10s`. The minimum
|
|
value for this setting is `5s`.
|