[role="xpack"] [[ml-settings]] === Machine learning settings in Elasticsearch ++++ Machine learning settings ++++ 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 <>. 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` (<>):: 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` (<>):: 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 <>. `xpack.ml.max_open_jobs` (<>):: 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` (<>):: 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` (<>):: Reserved. `xpack.ml.max_anomaly_records` (<>):: The maximum number of records that are output per bucket. The default value is `500`. `xpack.ml.max_lazy_ml_nodes` (<>):: 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` (<>):: 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`.