GOMAXPROCS usage instead of NumCPU for the pool size #1801
Merged
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.
What
runtime.GOMAXPROCS()
is used instead ofruntime.NumCPU()
to detect a default pool size.Why
We are running our services in the Kubernetes cluster and usually, each of them consumes (and is limited to) 2-3 CPUs.
But it's a logical restriction and
runtime.NumCPU()
will return all available CPUs on the node(64 in our case).That's why we set the
GOMAXPROCS
env variable to improve system's performance.In the current implementation, each of our services can create 5 * 64 connections to each Redis node, which in our case means ~300 * 5 * 64 = ~100k connections to the single node (if I'm not mistaken)
Thanks to the lazy connection initialization it happens rarely and completely unexpected. Once service or Redis node is busy the client starts generating a huge number of connections:
Pros and cons
The main benefit of the change will be the more reasonable defaults. Less unexpected behavior and fewer incidents in production :)
The main downside is that default behavior has changed in some cases. In most cases, GOMAXPROCS is equal to num CPU, but sometimes is not. But I do believe that it's more reasonable value and more aligned with the original purpose of using
NumCPU()
as a pool size