Share netty event loops between transports #46346
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently Elasticsearch creates independent event loop groups for each transport (http and internal) transport type. This is unnecessary and can lead to contention when different threads access shared resources (ex: allocators). This commit moves to a model where, by default, the event loops are shared between the transports. The previous behavior can be attained by specifically setting the http worker count.
Tim-Brooks
added
>non-issue
:Distributed/Network
|
Pinging @elastic/es-distributed |
ywelsch
suggested changes
Sep 27, 2019
.../transport-netty4/src/main/java/org/elasticsearch/http/netty4/Netty4HttpServerTransport.java
Outdated
Show resolved
Hide resolved
modules/transport-netty4/src/main/java/org/elasticsearch/transport/Netty4Plugin.java
Outdated
Show resolved
Hide resolved
modules/transport-netty4/src/main/java/org/elasticsearch/transport/SharedGroupFactory.java
Outdated
Show resolved
Hide resolved
modules/transport-netty4/src/main/java/org/elasticsearch/transport/SharedGroupFactory.java
Outdated
Show resolved
Hide resolved
modules/transport-netty4/src/main/java/org/elasticsearch/transport/netty4/Netty4Transport.java
Show resolved
Hide resolved
modules/transport-netty4/src/main/java/org/elasticsearch/transport/SharedGroupFactory.java
Show resolved
Hide resolved
|
I updated this for the comments. I'm not sure what to do on the thread count thing. I know in the team-discuss we said maybe we should reduce the make the minimum at least 4 (because 4 was theoretically the single core minimum before). But the setting allows the user to configure a minimum of 1 which means I would be breaking that. Are we okay with that? |
ywelsch
reviewed
Oct 24, 2019
modules/transport-netty4/src/main/java/org/elasticsearch/transport/SharedGroupFactory.java
Outdated
Show resolved
Hide resolved
| assertFalse(transportGroup.getLowLevelGroup().isShuttingDown()); | ||
| transportGroup.shutdown(); | ||
| assertTrue(httpGroup.getLowLevelGroup().isShuttingDown()); | ||
| assertTrue(transportGroup.getLowLevelGroup().isShuttingDown()); |
There was a problem hiding this comment.
can you also check the termination future? i.e. whether the shutdown has actually completed here?
modules/transport-netty4/src/main/java/org/elasticsearch/transport/SharedGroupFactory.java
Show resolved
Hide resolved
|
I have addressed the previous comments on this PR. |
original-brownbear
approved these changes
May 11, 2020
Tim-Brooks
added a commit
to Tim-Brooks/elasticsearch
that referenced
this pull request
May 11, 2020
Currently Elasticsearch creates independent event loop groups for each transport (http and internal) transport type. This is unnecessary and can lead to contention when different threads access shared resources (ex: allocators). This commit moves to a model where, by default, the event loops are shared between the transports. The previous behavior can be attained by specifically setting the http worker count.
DaveCTurner
added a commit
to DaveCTurner/elasticsearch
that referenced
this pull request
Jan 27, 2021
In elastic#46346 we changed the distribution of work across event loops but this was marked as a `>non-issue` so did not get a mention in the release notes. However, plugin authors might need to be aware of this change, so this commit records it in the release notes as an enhancement instead. Closes elastic#67960
DaveCTurner
added a commit
that referenced
this pull request
Feb 8, 2021
In #46346 we changed the distribution of work across event loops but this was marked as a `>non-issue` so did not get a mention in the release notes. However, plugin authors might need to be aware of this change, so this commit records it in the release notes as an enhancement instead. Closes #67960
DaveCTurner
added a commit
that referenced
this pull request
Feb 8, 2021
In #46346 we changed the distribution of work across event loops but this was marked as a `>non-issue` so did not get a mention in the release notes. However, plugin authors might need to be aware of this change, so this commit records it in the release notes as an enhancement instead. Closes #67960
DaveCTurner
added a commit
that referenced
this pull request
Feb 8, 2021
In #46346 we changed the distribution of work across event loops but this was marked as a `>non-issue` so did not get a mention in the release notes. However, plugin authors might need to be aware of this change, so this commit records it in the release notes as an enhancement instead. Closes #67960
DaveCTurner
added a commit
that referenced
this pull request
Feb 8, 2021
In #46346 we changed the distribution of work across event loops but this was marked as a `>non-issue` so did not get a mention in the release notes. However, plugin authors might need to be aware of this change, so this commit records it in the release notes as an enhancement instead. Closes #67960
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently Elasticsearch creates independent event loop groups for each
transport (http and internal) transport type. This is unnecessary and
can lead to contention when different threads access shared resources
(ex: allocators). This commit moves to a model where, by default, the
event loops are shared between the transports. The previous behavior can
be attained by specifically setting the http worker count.