release-26.1: mmaprototype: fix panic when sls <= loadNoChange but nls > loadNoChange #160633
+121
−3
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.
Backport 2/2 commits from #160615 on behalf of @tbg.
When deciding whether a store should shed load, computeCandidatesForReplicaTransfer
was checking both sls (store-level) and nls (node-level) load summaries. If nls
indicated overload but sls did not, shedding would proceed anyway. This caused a
panic in sortTargetCandidateSetAndPick which requires loadThreshold > loadNoChange.
The fix is to only check sls when deciding if a store should shed. If sls <=
loadNoChange, the store itself isn't overloaded relative to candidates that can
receive the load. High nls with low sls means other stores on the node are
causing node-level overload, so shedding from this store wouldn't help.
Fixes #160569
Release justification: low risk fix for panics in mmaprototype