Skip to content

Optionally skip container-aware CPU detection when fixed concurrency is specified - #1582

Open
tomjzzhang wants to merge 4 commits into
envoyproxy:mainfrom
tomjzzhang:cpu_count
Open

Optionally skip container-aware CPU detection when fixed concurrency is specified#1582
tomjzzhang wants to merge 4 commits into
envoyproxy:mainfrom
tomjzzhang:cpu_count

Conversation

@tomjzzhang

Copy link
Copy Markdown
Contributor

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.

Signed-off-by: tomjzzhang <4367421+tomjzzhang@users.noreply.github.com>
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant