Skip to content
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

Shutdown ExecutorService(s) in multi node pipelines #3467

Merged
merged 3 commits into from
Jun 14, 2023

Conversation

sazzad16
Copy link
Collaborator

Some discussions can be found in e193365

@sazzad16 sazzad16 added the bug label Jun 13, 2023
@sazzad16 sazzad16 added this to the 4.4.x milestone Jun 13, 2023
@sazzad16 sazzad16 requested a review from yangbodong22011 June 13, 2023 15:04
@sazzad16
Copy link
Collaborator Author

Thanks @jslopezgithub for reporting respective issue.

@yangbodong22011
Copy link
Collaborator

@sazzad16 The current PR still frequently creates and destroys threads. I strongly insist on making the thread pool static, let's keep working on #3333 .

@sazzad16
Copy link
Collaborator Author

The current PR still frequently creates and destroys threads. I strongly insist on making the thread pool static, let's keep working on #3333 .

@yangbodong22011 Yes. But it may take at least a couple of days. A quick fix for the issue is kind of necessary at this moment.

@sazzad16 sazzad16 requested a review from yangbodong22011 June 14, 2023 07:15
@sazzad16 sazzad16 merged commit c33bdf7 into redis:master Jun 14, 2023
@sazzad16 sazzad16 deleted the executor-shutdown branch June 14, 2023 07:47
sazzad16 added a commit that referenced this pull request Jun 14, 2023
* Shutdown ExecutorService(s) in multi node pipelines

* Use only shutdownNow()

* format import
@sazzad16 sazzad16 modified the milestones: 4.4.x, 4.4.3 Mar 24, 2024
@dolavb
Copy link

dolavb commented Nov 4, 2024

We executed load testing with profiling and this change results in 45% of CPU being used for starting thread, incurring a latency cost equivalent to the network wait time for the Redis process to return on the completed command. Overall this change has been detrimental and would probably be better with executing the whole pipeline on a single thread in our case.

@sazzad16
Copy link
Collaborator Author

sazzad16 commented Nov 5, 2024

@dolavb I think you actually mean the changes in #3331. Right? If so, have you tried setting MULTI_NODE_PIPELINE_SYNC_WORKERS = 1?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants