Optionally skip container-aware CPU detection when fixed concurrency is specified - #1582
Open
tomjzzhang wants to merge 4 commits into
Open
Optionally skip container-aware CPU detection when fixed concurrency is specified#1582tomjzzhang wants to merge 4 commits into
tomjzzhang wants to merge 4 commits into
Conversation
Signed-off-by: tomjzzhang <4367421+tomjzzhang@users.noreply.github.com>
… concurrency is set to auto Signed-off-by: tomjzzhang <4367421+tomjzzhang@users.noreply.github.com>
Signed-off-by: tomjzzhang <4367421+tomjzzhang@users.noreply.github.com>
This file contains hidden or 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
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.
Problem
During Nighthawk client startup, the option resolution logic in determineConcurrency() unconditionally executes Envoy::OptionsImplPlatform::getCpuCount() to initialize a default concurrency value.
The getCpuCount() function performs container-aware CPU limit detection by discovering cgroup mounts (parsing /proc/self/mountinfo) and reading cgroup limit files.
In certain environments (e.g., highly restricted sandboxes, container runtimes with virtualized /proc systems, or hosts with hung network mounts), reading these system files can block indefinitely. Because this detection was executed unconditionally, Nighthawk would hang during startup even when the user explicitly requested a fixed concurrency (e.g., --concurrency 1), where the auto-detected value is ultimately discarded.
This behavior also diverged from Envoy's own options parsing, which skips CPU count detection when --concurrency is set to a fixed value.
Solution
This PR wraps the getCpuCount() call in a conditional check so it is only executed when concurrency is set to "auto".
If a fixed concurrency is specified (e.g., --concurrency 1), we parse it directly and bypass the CPU detection logic entirely. This prevents startup hangs in environments with cgroup read limitations and aligns Nighthawk's options handling behavior with Envoy's.
Risk
Low. This change only affects the startup code path and behaves identically to the previous implementation when --concurrency=auto is used. When a fixed concurrency is passed, it safely avoids unnecessary system file reads.
Testing
Verified that Nighthawk client/daemon starts up successfully and resolves concurrency correctly in environments where cgroup file reads previously blocked the startup process.