[DOCS] Removes the default size definition of thread pool types (#49442)
Co-Authored-By: James Rodewig <james.rodewig@elastic.co>
This commit is contained in:
parent
d444c334d7
commit
35cc0e0948
|
@ -10,7 +10,7 @@ of discarded.
|
|||
There are several thread pools, but the important ones include:
|
||||
|
||||
`generic`::
|
||||
For generic operations (e.g., background node discovery).
|
||||
For generic operations (for example, background node discovery).
|
||||
Thread pool type is `scaling`.
|
||||
|
||||
`search`::
|
||||
|
@ -20,8 +20,9 @@ There are several thread pools, but the important ones include:
|
|||
`1000`.
|
||||
|
||||
[[search-throttled]]`search_throttled`::
|
||||
For count/search/suggest/get operations on `search_throttled indices`. Thread pool type is
|
||||
`fixed_auto_queue_size` with a size of `1`, and initial queue_size of `100`.
|
||||
For count/search/suggest/get operations on `search_throttled indices`.
|
||||
Thread pool type is `fixed_auto_queue_size` with a size of `1`, and initial
|
||||
queue_size of `100`.
|
||||
|
||||
`get`::
|
||||
For get operations. Thread pool type is `fixed`
|
||||
|
@ -29,7 +30,8 @@ There are several thread pools, but the important ones include:
|
|||
queue_size of `1000`.
|
||||
|
||||
`analyze`::
|
||||
For analyze requests. Thread pool type is `fixed` with a size of 1, queue size of 16.
|
||||
For analyze requests. Thread pool type is `fixed` with a size of `1`, queue
|
||||
size of `16`.
|
||||
|
||||
`write`::
|
||||
For single-document index/delete/update and bulk requests. Thread pool type
|
||||
|
@ -49,8 +51,9 @@ There are several thread pools, but the important ones include:
|
|||
keep-alive of `5m` and a max of `min(10, (# of available processors)/2)`.
|
||||
|
||||
`listener`::
|
||||
Mainly for java client executing of action when listener threaded is set to true.
|
||||
Thread pool type is `scaling` with a default max of `min(10, (# of available processors)/2)`.
|
||||
Mainly for java client executing of action when listener threaded is set to
|
||||
`true`. Thread pool type is `scaling` with a default max of
|
||||
`min(10, (# of available processors)/2)`.
|
||||
|
||||
`fetch_shard_started`::
|
||||
For listing shard states.
|
||||
|
@ -101,8 +104,7 @@ The `fixed` thread pool holds a fixed size of threads to handle the
|
|||
requests with a queue (optionally bounded) for pending requests that
|
||||
have no threads to service them.
|
||||
|
||||
The `size` parameter controls the number of threads, and defaults to the
|
||||
number of cores times 5.
|
||||
The `size` parameter controls the number of threads.
|
||||
|
||||
The `queue_size` allows to control the size of the queue of pending
|
||||
requests that have no threads to execute them. By default, it is set to
|
||||
|
@ -131,8 +133,7 @@ https://en.wikipedia.org/wiki/Little%27s_law[Little's Law]. These calculations
|
|||
will potentially adjust the `queue_size` up or down by 50 every time
|
||||
`auto_queue_frame_size` operations have been completed.
|
||||
|
||||
The `size` parameter controls the number of threads, and defaults to the
|
||||
number of cores times 5.
|
||||
The `size` parameter controls the number of threads.
|
||||
|
||||
The `queue_size` allows to control the initial size of the queue of pending
|
||||
requests that have no threads to execute them.
|
||||
|
@ -187,6 +188,7 @@ thread_pool:
|
|||
[float]
|
||||
[[processors]]
|
||||
=== Processors setting
|
||||
|
||||
The number of processors is automatically detected, and the thread pool
|
||||
settings are automatically set based on it. In some cases it can be
|
||||
useful to override the number of detected processors. This can be done
|
||||
|
@ -200,15 +202,14 @@ processors: 2
|
|||
There are a few use-cases for explicitly overriding the `processors`
|
||||
setting:
|
||||
|
||||
. If you are running multiple instances of Elasticsearch on the same
|
||||
host but want Elasticsearch to size its thread pools as if it only has a
|
||||
fraction of the CPU, you should override the `processors` setting to the
|
||||
desired fraction (e.g., if you're running two instances of Elasticsearch
|
||||
on a 16-core machine, set `processors` to 8). Note that this is an
|
||||
expert-level use-case and there's a lot more involved than just setting
|
||||
the `processors` setting as there are other considerations like changing
|
||||
the number of garbage collector threads, pinning processes to cores,
|
||||
etc.
|
||||
. If you are running multiple instances of {es} on the same host but want {es}
|
||||
to size its thread pools as if it only has a fraction of the CPU, you should
|
||||
override the `processors` setting to the desired fraction, for example, if
|
||||
you're running two instances of {es} on a 16-core machine, set `processors` to 8.
|
||||
Note that this is an expert-level use case and there's a lot more involved
|
||||
than just setting the `processors` setting as there are other considerations
|
||||
like changing the number of garbage collector threads, pinning processes to
|
||||
cores, and so on.
|
||||
. Sometimes the number of processors is wrongly detected and in such
|
||||
cases explicitly setting the `processors` setting will workaround such
|
||||
issues.
|
||||
|
|
Loading…
Reference in New Issue