Reduce idle CPU usage with adaptive poll backoff - #46
Merged
Conversation
Idle workers busy-polled Redis every 10ms, generating ~100 EVALSHA round-trips per second per consumer thread. The wait between acquire attempts now doubles on consecutive empty polls from poll_interval (default 10ms) up to poll_max_interval (default 1s) and resets on task pickup, keeping idle CPU usage low while bounding empty-queue pickup latency by poll_max_interval. Misconfigured options fail fast at construction: poll_interval must be a positive timedelta and poll_max_interval at least poll_interval, so a typo cannot silently spin workers unthrottled or crash-loop the pool. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Trust operator-provided values: illegal poll_interval or poll_max_interval settings may now crash the backend loudly instead of being rejected with a ValueError. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
--poll-interval and --poll-max-interval override the backend's idle poll options per worker run, in seconds. Overrides flow through the TaskExecutor into each worker process and are applied to the resolved backend before consumer threads start. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@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
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.
Why
Idle workers burned CPU by busy-polling Redis:
acquire()retried every 10ms, so each consumer thread issued ~100 EVALSHA round-trips per second while the pool sat empty, acrosscpu_count - 1worker processes.How
The wait between idle acquire attempts now doubles on every consecutive empty poll, from
poll_interval(default 10ms) up topoll_max_interval(default 1s), and resets on task pickup. On a local Redis, idle round-trips dropped from ~200 per 2 seconds to 9.OPTIONSand per worker run via--poll-interval/--poll-max-interval(seconds). The executor carries concrete defaults so every worker process applies the same values to its resolved backend before consumer threads start.TimeoutErrorandqueue.Emptybehave exactly as before.Trade-offs
poll_max_interval(up to 1s at the default) instead of 10ms. Idle-polling Redis for 10ms of responsiveness was the CPU cost being removed; lower the option if faster idle pickup matters.poll_interval/poll_max_intervalvalues are no longer rejected: zero dies withZeroDivisionErroron the first empty poll, negatives crash the consumer thread. Misconfiguration fails loudly rather than being silently rejected.