-
Notifications
You must be signed in to change notification settings - Fork 25.5k
Prioritise movement of shards in non-preferred allocations #135058
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prioritise movement of shards in non-preferred allocations #135058
Conversation
...ain/java/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocator.java
Outdated
Show resolved
Hide resolved
…hard_to_move_off_data_node_v2
if (canRemain.type() == Type.NOT_PREFERRED && bestNonPreferredShardsByNode.containsKey(shardRouting.currentNodeId())) { | ||
int compare = comparatorCache.computeIfAbsent( | ||
shardRouting.currentNodeId(), | ||
nodeId -> new ShardMovementPriorityComparator(allocation, allocation.routingNodes().node(nodeId)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By caching these, we are sorting all shards by the values calculated when the comparator was first created. It's likely that the threshold and maximum will move as shards are moved, but given that we don't move too much in each iteration, I think it's fine to accept the potential for slight differences.
…hard_to_move_off_data_node_v2
// Return after a single move so that the change can be simulated before further moves are made. | ||
return true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to check if (completeEarlyOnShardAssignmentChange)
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opted not to because it's happening after all the NO
moves and this is new behaviour, we know that we rely on the simulation being updated for these movements to make sense so I don't think we should ever attempt more than one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code changes look good to me, I left a few more suggestions.
I still need to look at the testing, but I've got an appointment, so publishing the comments I have.
...ain/java/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocator.java
Outdated
Show resolved
Hide resolved
...ain/java/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocator.java
Show resolved
Hide resolved
...ain/java/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocator.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to have IT testing with the DesiredBalanceShardsAllocator. This test could be updated: would need to give it a range of shard write loads, and then check that a specific shard was moved.
I'm totally fine with that testing being a follow up, however you prefer.
Left a lot of comments, but I think they're simple, so approving now. Let me know if you want me to take another look.
...ava/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocatorTests.java
Outdated
Show resolved
Hide resolved
...ava/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocatorTests.java
Show resolved
Hide resolved
...ava/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocatorTests.java
Outdated
Show resolved
Hide resolved
...ava/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocatorTests.java
Outdated
Show resolved
Hide resolved
...ava/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocatorTests.java
Outdated
Show resolved
Hide resolved
...ava/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocatorTests.java
Outdated
Show resolved
Hide resolved
...ava/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocatorTests.java
Outdated
Show resolved
Hide resolved
...ava/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocatorTests.java
Outdated
Show resolved
Hide resolved
...ava/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocatorTests.java
Show resolved
Hide resolved
...ava/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocatorTests.java
Outdated
Show resolved
Hide resolved
Buildkite benchmark this with many-shards-quantitative please |
💚 Build Succeeded
This build ran two many-shards-quantitative benchmarks to evaluate performance impact of this PR. History |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the IT testing. Looks good 👍
.../java/org/elasticsearch/cluster/routing/allocation/decider/WriteLoadConstraintDeciderIT.java
Outdated
Show resolved
Hide resolved
|
||
/** | ||
* Helper to create a list of dummy {@link ShardStats} for the given index, each shard reporting a {@code peakShardWriteLoad} stat. | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Method comment needs update
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 29a79e1
…routing/allocation/decider/WriteLoadConstraintDeciderIT.java Co-authored-by: Dianna Hohensee <[email protected]>
This approach keeps track of the best
NOT_PREFERRED
moves seen when iterating through looking forNO
s.If we get to the end of the
moveShards
loop and we can still make moves, we will pick one of theNOT_PREFERRED
moves to make.There is no prioritisation of
NO
moves in this approach, anything with a decider returningNO
will be moved as soon as we encounter it in the node-interleaved iterator.