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

(PUP-11897) Fix excessive cpu usage after EOF from an exec #9105

Closed
wants to merge 3 commits into from

Conversation

tvpartytonight
Copy link
Contributor

No description provided.

bugfood and others added 2 commits June 22, 2023 15:00
When EOF is reached, calls to IO.select() will return immediately,
resulting in puppet executing the loop without any internal blocking.
This causes up to 100% usage of a CPU core until the child finishes.

If the child does its own stdout/stderr redirection before a long
operation, for example, this can result in much wasted CPU usage.

There is no need to execute the body of the loop after EOF is reached,
so switch the Process.waitpid2 flags to block.
This adds testing for 4f35fd2 which fixes excessive core usage
when an exec has received an EOF.
@tvpartytonight tvpartytonight requested a review from a team as a code owner September 7, 2023 20:27
With the change in 4f35fd2, the execution tests need to have
mocked out the an addtional call to `waitpid2` that has the
flag set to zero.
@@ -235,6 +239,7 @@ def self.execute(command, options = NoOptionsSpecified)
output << reader.read_nonblock(4096) if ready
rescue Errno::EAGAIN
rescue EOFError
wait_flags &= ~Process::WNOHANG
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Masking off WNOHANG would make sense if something modified the variable between the time it was initialized to wait_flags = Process::WNOHANG and here. For example, if wait_flags was an in-and-out parameter in the call to Process.waitpid2. But since the variable isn't modified and the default value for the flags parameter is 0 (i.e. Process.waitpid2(pid, flags = 0)), then I think it'd be clearer to set this to wait_flags = 0.

@joshcooper
Copy link
Contributor

Superseded by #9106 which will be merged up to main later.

@joshcooper joshcooper closed this Sep 12, 2023
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.

3 participants