[PR #7939/d212f0b5 backport][3.115] fix: make redis workers to know the current num of workers at startup - #7941
Merged
gerrod3 merged 1 commit intoAug 3, 2026
Conversation
Signed-off-by: Carlos Feria <2582866+carlosthe19916@users.noreply.github.com> (cherry picked from commit d212f0b)
4 tasks
gerrod3
approved these changes
Aug 3, 2026
gerrod3
deleted the
patchback/backports/3.115/d212f0b5737f578fef0aaedb5e799872bca7202e/pr-7939
branch
August 3, 2026 15:58
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
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.
This is a backport of PR #7939 as merged into main (d212f0b).
Fixes: #7912
Addresses: https://redhat.atlassian.net/browse/PULP-2149
Problem
Redis workers find work by repeatedly asking the database for waiting tasks, then sleeping briefly. Sleep is supposed to get longer as the fleet grows, so many workers don’t all pound the DB at once.
But each new worker starts life assuming the fleet has one worker. It only learns the real count on its first heartbeat (~10s later). Until then it polls about every 10 ms.
So a scale-up (e.g. 25 → 150) creates a short window of thousands of SELECTs per second against core_task. The DB saturates, heartbeat writes fail, workers exit, replacements start, and the same aggressive startup polling happens again.
Solution
workers should learn fleet size at startup before first heartbeat
📜 Checklist
See: Pull Request Walkthrough