Skip to content

[8.7] Fix docs for transport_worker hot threads (#96346) #96351

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 25, 2023
Merged

[8.7] Fix docs for transport_worker hot threads (#96346) #96351

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions docs/reference/modules/network/threading.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -63,7 +63,7 @@ reported like this:

[source,text]
----
100.0% [cpu=0.0%, other=100.0%] (500ms out of 500ms) cpu usage by thread 'elasticsearch[instance-0000000004][transport_worker][T#1]'
0.0% [cpu=0.0%, idle=100.0%] (500ms out of 500ms) cpu usage by thread 'elasticsearch[instance-0000000004][transport_worker][T#1]'
10/10 snapshots sharing following 9 elements
[email protected]/sun.nio.ch.EPoll.wait(Native Method)
[email protected]/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:118)
Expand All @@ -78,10 +78,10 @@ reported like this:

Note that `transport_worker` threads should always be in state `RUNNABLE`, even
when waiting for input, because they block in the native `EPoll#wait` method.
This means the hot threads API will report these threads at 100% overall
utilisation. This is normal, and the breakdown of time into `cpu=` and `other=`
fractions shows how much time the thread spent running and waiting for input
respectively.
The `idle=` time reports the proportion of time the thread spent waiting for
input, whereas the `cpu=` time reports the proportion of time the thread spent
processing input it has received. If the thread was seen using absolutely no
CPU then it will report `0.0% [cpu=0.0%, idle=0.0%]`.

If a `transport_worker` thread is not frequently idle, it may build up a
backlog of work. This can cause delays in processing messages on the channels
Expand Down