ml-settings.asciidoc 5.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106
  1. [role="xpack"]
  2. [[ml-settings]]
  3. === Machine learning settings in Elasticsearch
  4. ++++
  5. <titleabbrev>Machine learning settings</titleabbrev>
  6. ++++
  7. You do not need to configure any settings to use {ml}. It is enabled by default.
  8. All of these settings can be added to the `elasticsearch.yml` configuration file.
  9. The dynamic settings can also be updated across a cluster with the
  10. <<cluster-update-settings,cluster update settings API>>.
  11. TIP: Dynamic settings take precedence over settings in the `elasticsearch.yml`
  12. file.
  13. [float]
  14. [[general-ml-settings]]
  15. ==== General machine learning settings
  16. `node.ml`::
  17. Set to `true` (default) to identify the node as a _machine learning node_. +
  18. +
  19. If set to `false` in `elasticsearch.yml`, the node cannot run jobs. If set to
  20. `true` but `xpack.ml.enabled` is set to `false`, the `node.ml` setting is
  21. ignored and the node cannot run jobs. If you want to run jobs, there must be at
  22. least one machine learning node in your cluster. +
  23. +
  24. IMPORTANT: On dedicated coordinating nodes or dedicated master nodes, disable
  25. the `node.ml` role.
  26. `xpack.ml.enabled`::
  27. Set to `true` (default) to enable {ml} on the node. +
  28. +
  29. If set to `false` in `elasticsearch.yml`, the {ml} APIs are disabled on the node.
  30. Therefore the node cannot open jobs, start {dfeeds}, or receive transport (internal)
  31. communication requests related to {ml} APIs. It also affects all {kib} instances
  32. that connect to this {es} instance; you do not need to disable {ml} in those
  33. `kibana.yml` files. For more information about disabling {ml} in specific {kib}
  34. instances, see
  35. {kibana-ref}/ml-settings-kb.html[{kib} Machine Learning Settings].
  36. +
  37. IMPORTANT: If you want to use {ml} features in your cluster, you must have
  38. `xpack.ml.enabled` set to `true` on all master-eligible nodes. This is the
  39. default behavior.
  40. `xpack.ml.max_machine_memory_percent` (<<cluster-update-settings,Dynamic>>)::
  41. The maximum percentage of the machine's memory that {ml} may use for running
  42. analytics processes. (These processes are separate to the {es} JVM.) Defaults to
  43. `30` percent. The limit is based on the total memory of the machine, not current
  44. free memory. Jobs will not be allocated to a node if doing so would cause the
  45. estimated memory use of {ml} jobs to exceed the limit.
  46. `xpack.ml.max_model_memory_limit` (<<cluster-update-settings,Dynamic>>)::
  47. The maximum `model_memory_limit` property value that can be set for any job on
  48. this node. If you try to create a job with a `model_memory_limit` property value
  49. that is greater than this setting value, an error occurs. Existing jobs are not
  50. affected when you update this setting. For more information about the
  51. `model_memory_limit` property, see <<ml-apilimits>>.
  52. `xpack.ml.max_open_jobs` (<<cluster-update-settings,Dynamic>>)::
  53. The maximum number of jobs that can run simultaneously on a node. Defaults to
  54. `20`. In this context, jobs include both anomaly detector jobs and data frame
  55. analytics jobs. The maximum number of jobs is also constrained by memory usage.
  56. Thus if the estimated memory usage of the jobs would be higher than allowed,
  57. fewer jobs will run on a node. Prior to version 7.1, this setting was a per-node
  58. non-dynamic setting. It became a cluster-wide dynamic
  59. setting in version 7.1. As a result, changes to its value after node startup
  60. are used only after every node in the cluster is running version 7.1 or higher.
  61. The maximum permitted value is `512`.
  62. `xpack.ml.node_concurrent_job_allocations` (<<cluster-update-settings,Dynamic>>)::
  63. The maximum number of jobs that can concurrently be in the `opening` state on
  64. each node. Typically, jobs spend a small amount of time in this state before
  65. they move to `open` state. Jobs that must restore large models when they are
  66. opening spend more time in the `opening` state. Defaults to `2`.
  67. [float]
  68. [[advanced-ml-settings]]
  69. ==== Advanced machine learning settings
  70. These settings are for advanced use cases; the default values are generally
  71. sufficient:
  72. `xpack.ml.enable_config_migration` (<<cluster-update-settings,Dynamic>>)::
  73. Reserved.
  74. `xpack.ml.max_anomaly_records` (<<cluster-update-settings,Dynamic>>)::
  75. The maximum number of records that are output per bucket. The default value is
  76. `500`.
  77. `xpack.ml.max_lazy_ml_nodes` (<<cluster-update-settings,Dynamic>>)::
  78. The number of lazily spun up Machine Learning nodes. Useful in situations
  79. where ML nodes are not desired until the first Machine Learning Job
  80. is opened. It defaults to `0` and has a maximum acceptable value of `3`.
  81. If the current number of ML nodes is `>=` than this setting, then it is
  82. assumed that there are no more lazy nodes available as the desired number
  83. of nodes have already been provisioned. When a job is opened with this
  84. setting set at `>0` and there are no nodes that can accept the job, then
  85. the job will stay in the `OPENING` state until a new ML node is added to the
  86. cluster and the job is assigned to run on that node.
  87. +
  88. IMPORTANT: This setting assumes some external process is capable of adding ML nodes
  89. to the cluster. This setting is only useful when used in conjunction with
  90. such an external process.