preview: Use dumb-init as PID 1 #2982
Merged
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
build_docs.pl runs a number of git commands through its normal course of operation. After a certain point, these git commands will implicitly run git gc in the background. By design, the original git process forks off the gc child process and forgets about it. The child process will get reparented to PID 1, which is either build_docs.pl or a shell. Neither of those will handle SIGCHLD for processes they're not aware of, so the number of zombie processes grows indefinitely. With a large number of zombie processes (80k processes observed in elastic-apps-web), metricbeat starts consuming all available CPU resources, severely degradating the performance of the cluster. This has a side effect of reducing the network performance to around ~50Mbps and increasing the I/O wait to ~30%. dumb-init was picked because it's dumb and doesn't try to do anything fancy. There should be nothing that interferes with build_docs.pl's operation. Signals are forwarded to dumb-init's child. dumb-init will also detach itself from the controlling TTY and attach its child process instead. Ticket: https://elasticco.atlassian.net/browse/SRVCS-1367 Signed-off-by: Andrew Gunnerson <[email protected]>
|
A documentation preview will be available soon. Request a new doc build by commenting
If your PR continues to fail for an unknown reason, the doc build pipeline may be broken. Elastic employees can check the pipeline status here. |
gtback
approved these changes
Apr 9, 2024
There was a problem hiding this comment.
Great investigation and thorough explanation, @agunnerson-elastic ! I'm not familiar with dumb-init (I've often seen tini used for this purpose) but it seems to do exactly what we need.
cc: @nik9000 in case you know of anything related to docs-preview that might be relevant that I'm not aware of.
|
It also looks like my review isn't enough here, since I'm not an owner of this repo anymore 🙃 |
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.
build_docs.plruns a number of git commands through its normal course of operation. After a certain point, these git commands will implicitly rungit gcin the background. By design, the original git process forks off the gc child process and forgets about it. The child process will get reparented to PID 1, which is eitherbuild_docs.plor a shell. Neither of those will handleSIGCHLDfor processes they're not aware of, so the number of zombie processes grows indefinitely.With a large number of zombie processes (80k processes observed in elastic-apps-web), metricbeat starts consuming all available CPU resources, severely degradating the performance of the cluster. This has a side effect of reducing the network performance to around ~50Mbps and increasing the I/O wait to ~30%.
dumb-init was picked because it's dumb and doesn't try to do anything fancy. There should be nothing that interferes with
build_docs.pl's operation. Signals are forwarded to dumb-init's child. dumb-init will also detach itself from the controlling TTY and attach its child process instead.Ticket: https://elasticco.atlassian.net/browse/SRVCS-1367
(2024-04-12 update: This has been successfully tested in the elastic-apps-web cluster.)