Skip to content

Commit ec09576

Browse files
committed
Use node.processors in favor of processors in docs
The processors setting was deprecated in favor of node.processors. This commit addresses an issue in the docs where we were still referring to processors.
1 parent 2b9f048 commit ec09576

File tree

1 file changed

+17
-18
lines changed

1 file changed

+17
-18
lines changed

docs/reference/modules/threadpool.asciidoc

Lines changed: 17 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -191,32 +191,31 @@ thread_pool:
191191

192192
[float]
193193
[[processors]]
194-
=== Processors setting
194+
=== Allocated processors setting
195195

196-
The number of processors is automatically detected, and the thread pool
197-
settings are automatically set based on it. In some cases it can be
198-
useful to override the number of detected processors. This can be done
199-
by explicitly setting the `processors` setting.
196+
The number of processors is automatically detected, and the thread pool settings
197+
are automatically set based on it. In some cases it can be useful to override
198+
the number of detected processors. This can be done by explicitly setting the
199+
`node.processors` setting.
200200

201201
[source,yaml]
202202
--------------------------------------------------
203-
processors: 2
203+
node.processors: 2
204204
--------------------------------------------------
205205

206-
There are a few use-cases for explicitly overriding the `processors`
206+
There are a few use-cases for explicitly overriding the `node.processors`
207207
setting:
208208

209-
. If you are running multiple instances of {es} on the same host but want {es}
210-
to size its thread pools as if it only has a fraction of the CPU, you should
211-
override the `processors` setting to the desired fraction, for example, if
212-
you're running two instances of {es} on a 16-core machine, set `processors` to 8.
213-
Note that this is an expert-level use case and there's a lot more involved
214-
than just setting the `processors` setting as there are other considerations
215-
like changing the number of garbage collector threads, pinning processes to
216-
cores, and so on.
217-
. Sometimes the number of processors is wrongly detected and in such
218-
cases explicitly setting the `processors` setting will workaround such
219-
issues.
209+
. If you are running multiple instances of {es} on the same host but want want
210+
{es} to size its thread pools as if it only has a fraction of the CPU, you
211+
should override the `node.processors` setting to the desired fraction, for
212+
example, if you're running two instances of {es} on a 16-core machine, set
213+
`node.processors` to 8. Note that this is an expert-level use case and there's
214+
a lot more involved than just setting the `node.processors` setting as there are
215+
other considerations like changing the number of garbage collector threads,
216+
pinning processes to cores, and so on.
217+
. Sometimes the number of processors is wrongly detected and in such cases
218+
explicitly setting the `node.processors` setting will workaround such issues.
220219

221220
In order to check the number of processors detected, use the nodes info
222221
API with the `os` flag.

0 commit comments

Comments
 (0)