fix exec_* startup delay if nofile is too high#1750
Draft
Jamesits wants to merge 2 commits intoarut:masterfrom
Draft
fix exec_* startup delay if nofile is too high#1750Jamesits wants to merge 2 commits intoarut:masterfrom
Jamesits wants to merge 2 commits intoarut:masterfrom
Conversation
Jamesits
changed the title
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
1 participant
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.
Currently we rely on a for loop to close all possible file descriptors, and when nofile is set to a large number (a very common case in Nginx deployments), the worker process might eat up a single core for a few minutes(!) after
forkand beforeexec. This results in unexpected server performance impacts, and causesexec_pushandexec_pullto be delayed a lot (e.g. you can't do low-latency realtime transcode anymore). Others have pointed out this problem but lowering nofiles is not a long term solution.This patch resolves the performance issue, and have been steadily runnning in my environment for a while. But it requires Linux 5.9 + glibc 2.34, or FreeBSD 8.0+. I'm not sure if we can detect the existence of
close_rangeinconfigureas I'm not really familiar of Nginx's build system conventions. I'd like to refine its compatibility if possible.