-
Notifications
You must be signed in to change notification settings - Fork 6.7k
[core] Patch grpc with RAY_num_grpc_threads to control grpc thread count #54988
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.
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @ZacAttack, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
I've implemented a core change to address thread bloat in Ray worker processes, specifically targeting gRPC's thread usage. This change allows users to explicitly control the number of gRPC threads by setting a new environment variable, RAY_num_grpc_threads
, via Ray's RuntimeEnv
. This provides an incremental step towards optimizing resource utilization and reducing unnecessary thread overhead in worker processes.
Highlights
- gRPC Thread Control: I've introduced a new mechanism to control the number of gRPC threads spawned by Ray workers. This is achieved by applying a custom patch to the gRPC library during the build process.
RAY_num_grpc_threads
Environment Variable: This pull request enables the use of theRAY_num_grpc_threads
environment variable. When this variable is set in theRuntimeEnv
for a Ray worker, gRPC will use the specified value as its thread pool size. This allows for fine-grained control over thread resource consumption.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
Warning Gemini encountered an error creating the review. You can try again by commenting |
(does not seem to require ray-ci to review?) |
Co-authored-by: Jiajun Yao <jeromeyjj@gmail.com> Signed-off-by: Zac Policzer <zacattackftw@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: let's name the patch something like grpc-configurable-thread-count
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One nit, a merge conflict, then LGTM
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
@ZacAttack I fixed merge conflict but please fix DCO (sign off commits) |
Signed-off-by: zac <zac@anyscale.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚢 nicely done!
…unt (#54988) Signed-off-by: Zac Policzer <zacattackftw@gmail.com> Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com> Signed-off-by: zac <zac@anyscale.com> Co-authored-by: Jiajun Yao <jeromeyjj@gmail.com> Co-authored-by: Edward Oakes <ed.nmi.oakes@gmail.com> Signed-off-by: sampan <sampan@anyscale.com>
…unt (ray-project#54988) Signed-off-by: Zac Policzer <zacattackftw@gmail.com> Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com> Signed-off-by: zac <zac@anyscale.com> Co-authored-by: Jiajun Yao <jeromeyjj@gmail.com> Co-authored-by: Edward Oakes <ed.nmi.oakes@gmail.com> Signed-off-by: Andrew Grosser <dioptre@gmail.com>
Why are these changes needed?
Workers spawn extraneous threads that aren't necessary. It's been identified that a major source of thread bloat is coming from the use of grpc in the worker processes. As an incremental step towards a full resolution, this patch adds "RAY_worker_num_grpc_internal_threads" as an environment variable which is honored by the raylet when spawning workers. Setting this environment variable in your base image or in your code will limit the number of threads spawned by grpc in the worker.
An example usage of this api would look like:
Related issue number
Closes #36936
Closes #54225
Checks
git commit -s
) in this PR.scripts/format.sh
to lint the changes in this PR.method in Tune, I've added it in
doc/source/tune/api/
under thecorresponding
.rst
file.