ml-settings.asciidoc 9.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192
  1. [role="xpack"]
  2. [[ml-settings]]
  3. === Machine learning settings in Elasticsearch
  4. ++++
  5. <titleabbrev>Machine learning settings</titleabbrev>
  6. ++++
  7. [[ml-settings-description]]
  8. // tag::ml-settings-description-tag[]
  9. You do not need to configure any settings to use {ml}. It is enabled by default.
  10. IMPORTANT: {ml-cap} uses SSE4.2 instructions, so it works only on machines whose
  11. CPUs {wikipedia}/SSE4#Supporting_CPUs[support] SSE4.2. If you run {es} on older
  12. hardware, you must disable {ml} (by setting `xpack.ml.enabled` to `false`).
  13. // end::ml-settings-description-tag[]
  14. [discrete]
  15. [[general-ml-settings]]
  16. ==== General machine learning settings
  17. `node.roles: [ ml ]`::
  18. (<<static-cluster-setting,Static>>) Set `node.roles` to contain `ml` to identify
  19. the node as a _{ml} node_ that is capable of running jobs. Every node is a {ml}
  20. node by default.
  21. +
  22. If you use the `node.roles` setting, then all required roles must be explicitly
  23. set. Consult <<modules-node>> to learn more.
  24. +
  25. IMPORTANT: On dedicated coordinating nodes or dedicated master nodes, do not set
  26. the `ml` role.
  27. `xpack.ml.enabled`::
  28. (<<static-cluster-setting,Static>>) Set to `true` (default) to enable {ml} APIs
  29. on the node.
  30. +
  31. If set to `false`, the {ml} APIs are disabled on the node. Therefore the node
  32. cannot open jobs, start {dfeeds}, or receive transport (internal) communication
  33. requests related to {ml} APIs. If the node is a coordinating node, {ml} requests
  34. from clients (including {kib}) also fail. For more information about disabling
  35. {ml} in specific {kib} instances, see
  36. {kibana-ref}/ml-settings-kb.html[{kib} {ml} settings].
  37. +
  38. IMPORTANT: If you want to use {ml-features} in your cluster, it is recommended
  39. that you set `xpack.ml.enabled` to `true` on all nodes. This is the default
  40. behavior. At a minimum, it must be enabled on all master-eligible nodes. If you
  41. want to use {ml-features} in clients or {kib}, it must also be enabled on all
  42. coordinating nodes.
  43. `xpack.ml.inference_model.cache_size`::
  44. (<<static-cluster-setting,Static>>) The maximum inference cache size allowed.
  45. The inference cache exists in the JVM heap on each ingest node. The cache
  46. affords faster processing times for the `inference` processor. The value can be
  47. a static byte sized value (i.e. "2gb") or a percentage of total allocated heap.
  48. The default is "40%". See also <<model-inference-circuit-breaker>>.
  49. [[xpack-interference-model-ttl]]
  50. // tag::interference-model-ttl-tag[]
  51. `xpack.ml.inference_model.time_to_live` {ess-icon}::
  52. (<<static-cluster-setting,Static>>) The time to live (TTL) for models in the
  53. inference model cache. The TTL is calculated from last access. The `inference`
  54. processor attempts to load the model from cache. If the `inference` processor
  55. does not receive any documents for the duration of the TTL, the referenced model
  56. is flagged for eviction from the cache. If a document is processed later, the
  57. model is again loaded into the cache. Defaults to `5m`.
  58. // end::interference-model-ttl-tag[]
  59. `xpack.ml.max_inference_processors`::
  60. (<<cluster-update-settings,Dynamic>>) The total number of `inference` type
  61. processors allowed across all ingest pipelines. Once the limit is reached,
  62. adding an `inference` processor to a pipeline is disallowed. Defaults to `50`.
  63. `xpack.ml.max_machine_memory_percent`::
  64. (<<cluster-update-settings,Dynamic>>) The maximum percentage of the machine's
  65. memory that {ml} may use for running analytics processes. (These processes are
  66. separate to the {es} JVM.) Defaults to `30` percent. The limit is based on the
  67. total memory of the machine, not current free memory. Jobs are not allocated to
  68. a node if doing so would cause the estimated memory use of {ml} jobs to exceed
  69. the limit.
  70. `xpack.ml.max_model_memory_limit`::
  71. (<<cluster-update-settings,Dynamic>>) The maximum `model_memory_limit` property
  72. value that can be set for any job on this node. If you try to create a job with
  73. a `model_memory_limit` property value that is greater than this setting value,
  74. an error occurs. Existing jobs are not affected when you update this setting.
  75. For more information about the `model_memory_limit` property, see
  76. <<put-analysislimits>>.
  77. [[xpack.ml.max_open_jobs]]
  78. `xpack.ml.max_open_jobs`::
  79. (<<cluster-update-settings,Dynamic>>) The maximum number of jobs that can run
  80. simultaneously on a node. Defaults to `20`. In this context, jobs include both
  81. {anomaly-jobs} and {dfanalytics-jobs}. The maximum number of jobs is also
  82. constrained by memory usage. Thus if the estimated memory usage of the jobs
  83. would be higher than allowed, fewer jobs will run on a node. Prior to version
  84. 7.1, this setting was a per-node non-dynamic setting. It became a cluster-wide
  85. dynamic setting in version 7.1. As a result, changes to its value after node
  86. startup are used only after every node in the cluster is running version 7.1 or
  87. higher. The maximum permitted value is `512`.
  88. `xpack.ml.nightly_maintenance_requests_per_second`::
  89. (<<cluster-update-settings,Dynamic>>) The rate at which the nightly maintenance task
  90. deletes expired model snapshots and results. The setting is a proxy to the
  91. [requests_per_second](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete-by-query.html#_throttling_delete_requests)
  92. parameter used in the Delete by query requests and controls throttling.
  93. Valid values must be greater than `0.0` or equal to `-1.0` where `-1.0` means a default value
  94. is used. Defaults to `-1.0`
  95. `xpack.ml.node_concurrent_job_allocations`::
  96. (<<cluster-update-settings,Dynamic>>) The maximum number of jobs that can
  97. concurrently be in the `opening` state on each node. Typically, jobs spend a
  98. small amount of time in this state before they move to `open` state. Jobs that
  99. must restore large models when they are opening spend more time in the `opening`
  100. state. Defaults to `2`.
  101. [discrete]
  102. [[advanced-ml-settings]]
  103. ==== Advanced machine learning settings
  104. These settings are for advanced use cases; the default values are generally
  105. sufficient:
  106. `xpack.ml.enable_config_migration`::
  107. (<<cluster-update-settings,Dynamic>>) Reserved.
  108. `xpack.ml.max_anomaly_records`::
  109. (<<cluster-update-settings,Dynamic>>) The maximum number of records that are
  110. output per bucket. The default value is `500`.
  111. `xpack.ml.max_lazy_ml_nodes`::
  112. (<<cluster-update-settings,Dynamic>>) The number of lazily spun up {ml} nodes.
  113. Useful in situations where {ml} nodes are not desired until the first {ml} job
  114. opens. It defaults to `0` and has a maximum acceptable value of `3`. If the
  115. current number of {ml} nodes is greater than or equal to this setting, it is
  116. assumed that there are no more lazy nodes available as the desired number
  117. of nodes have already been provisioned. If a job is opened and this setting has
  118. a value greater than zero and there are no nodes that can accept the job, the
  119. job stays in the `OPENING` state until a new {ml} node is added to the cluster
  120. and the job is assigned to run on that node.
  121. +
  122. IMPORTANT: This setting assumes some external process is capable of adding {ml}
  123. nodes to the cluster. This setting is only useful when used in conjunction with
  124. such an external process.
  125. `xpack.ml.process_connect_timeout`::
  126. (<<cluster-update-settings,Dynamic>>) The connection timeout for {ml} processes
  127. that run separately from the {es} JVM. Defaults to `10s`. Some {ml} processing
  128. is done by processes that run separately to the {es} JVM. When such processes
  129. are started they must connect to the {es} JVM. If such a process does not
  130. connect within the time period specified by this setting then the process is
  131. assumed to have failed. Defaults to `10s`. The minimum value for this setting is
  132. `5s`.
  133. xpack.ml.use_auto_machine_memory_percent::
  134. (<<static-cluster-setting,Static>>) If this setting is `true`, the
  135. `xpack.ml.max_machine_memory_percent` setting is ignored. Instead, the maximum
  136. percentage of the machine's memory that can be used for running {ml} analytics
  137. processes is calculated automatically and takes into account the total node size
  138. and the size of the JVM on the node. The default value is `false`. If this
  139. setting differs between nodes, the value on the current master node is heeded.
  140. +
  141. TIP: If you do not have dedicated {ml} nodes (that is to say, the node has
  142. multiple roles), do not enable this setting. Its calculations assume that {ml}
  143. analytics are the main purpose of the node.
  144. +
  145. IMPORTANT: The calculation assumes that dedicated {ml} nodes have at least
  146. `256MB` memory reserved outside of the JVM. If you have tiny {ml}
  147. nodes in your cluster, you shouldn't use this setting.
  148. [discrete]
  149. [[model-inference-circuit-breaker]]
  150. ==== {ml-cap} circuit breaker settings
  151. `breaker.model_inference.limit`::
  152. (<<cluster-update-settings,Dynamic>>) Limit for the model inference breaker,
  153. which defaults to 50% of the JVM heap. If the parent circuit breaker is less
  154. than 50% of the JVM heap, it is bound to that limit instead. See
  155. <<circuit-breaker>>.
  156. `breaker.model_inference.overhead`::
  157. (<<cluster-update-settings,Dynamic>>) A constant that all accounting estimations
  158. are multiplied by to determine a final estimation. Defaults to 1. See
  159. <<circuit-breaker>>.
  160. `breaker.model_inference.type`::
  161. (<<static-cluster-setting,Static>>) The underlying type of the circuit breaker.
  162. There are two valid options: `noop` and `memory`. `noop` means the circuit
  163. breaker does nothing to prevent too much memory usage. `memory` means the
  164. circuit breaker tracks the memory used by inference models and can potentially
  165. break and prevent `OutOfMemory` errors. The default is `memory`.