fix(zstd): default back to GOMAXPROCS concurrency #2404
Merged
+1
−1
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
An upstream change in klauspost/compress#498 changed the default decoder concurrency from GOMAXPROCS to a maximum of 4. Explicitly pass a value of 0 via WithDecoderConcurrency so that GOMAXPROCS is used by default again.
|
I signed the CLA. I don't see a way to rerun the job. |
dnwe
approved these changes
Dec 21, 2022
dnwe
changed the title
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.
After upgrading Sarama from 1.27.0 to 1.37.2, we noticed a significant performance regression in one of our services. This service runs on a very large (96 CPU) instance, and normally processes about 120K messages/sec. After the upgrade, it could only do about half that.
We traced the issue to this change in klauspost/compress. Since Sarama uses the defaults when creating a new reader, concurrency is limited to 4.
By setting
WithDecoderConcurrency(0), concurrency is set toGOMAXPROCS(which in our app is set toruntime.NumCPU()== 96. When we deployed our service with this change, our performance issue disappeared.