-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Account for simulated utilization threshold in WriteLoadConstraintDeciderIT #133894
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
Account for simulated utilization threshold in WriteLoadConstraintDeciderIT #133894
Conversation
|
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
| public void testHighNodeWriteLoadPreventsNewShardAllocation() { | ||
| int randomUtilizationThresholdPercent = randomIntBetween(50, 100); | ||
| int numberOfWritePoolThreads = randomIntBetween(10, 20); | ||
| double shardWriteLoad = randomDoubleBetween(0.0, 0.2, 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.
Would probably be a lot easier to reason about if shard write loads were zero (then there would be no risk of the decider preventing the movement because it would overload the target), but also less realistic.
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 only constraint for the shard write load in this test is that it is greater than zero so that the WriteLoadDecider considers it. So we could use a very small shard write load. I didn't originally realize the simulator factor when writing this test, clearly :) So I just picked a random value.
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.
Ahh of course... I changed lowerInclusive to false in ba15f8f to ensure we don't get zeros
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.
Some minor comments
| */ | ||
| public void testHighNodeWriteLoadPreventsNewShardAllocation() { | ||
| int randomUtilizationThresholdPercent = randomIntBetween(50, 100); | ||
| int numberOfWritePoolThreads = randomIntBetween(10, 20); |
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 think the lower bound of the randomization should be 2 since that's a realistic setup.
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.
Lowering the thread count might result in the shards being unable to fit on a single node, I expect. Not sure how much we care about realism. We could lower the shardWriteLoad to 0.001, to remove that concern -- and give the threshold randomization a bigger range of values.
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 ba15f8f
| thirdDiscoveryNode, | ||
| 2, | ||
| numberOfWritePoolThreads, | ||
| randomUtilizationThresholdPercent + 1 / 100, |
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.
Should this be randomIntBetween(0, maxUtilizationPercent) / 100f, as well?
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.
No, the test works by
- Create an index while
cluster.routing.allocation.exclude._name = "secondDataNode, thirdDataNode"(all shards are assigned tofirstDataNode) - Mock the
TransportNodeUsageStatsForThreadPoolsActionon the three data nodes such that the first and second nodes report being under the utilisation threshold, and the third node reports being over the utilisation threshold.- Also mock the shard write load responses (random between 0 and something, I don't think this is critical to the test)
- Refresh cluster info
- Update
cluster.routing.allocation.exclude._name = "firstDataNode" - Wait to see all the shards relocated to
secondDataNodebecause first is excluded, and third is over the utilisation threshold.
So we have to have it over the threshold 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.
Thanks for diagnosing and fixing this, Nick! I left a few cosmetic requests, but lgtm.
Could you change the commit message to something like "Account for simulated utilization threshold in WriteLoadConstraintDeciderIT" ? Fix is very vague.
| int randomNumberOfShards = randomIntBetween(10, 20); // Pick a high number of shards, so it is clear assignment is not accidental. | ||
|
|
||
| // Calculate the maximum utilization a node can report while still being able to accept all relocating shards | ||
| double additionalLoadFromAllShards = (shardWriteLoad * randomNumberOfShards) / numberOfWritePoolThreads; |
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.
Could you make this a method helper in this test file -- takes total shard write load, number of threads, returns needed overheard?
I lean towards making this sort of calculation a static method on the ShardMovementWriteLoadSimulator, because it's fragile to simulator calculation changes, but of more immediately interest is we will likely repeat this calculation for future testing.
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's a bit basic, but I added it here. Perhaps having a name for it makes it clearer what's going on 946469e
| public void testHighNodeWriteLoadPreventsNewShardAllocation() { | ||
| int randomUtilizationThresholdPercent = randomIntBetween(50, 100); | ||
| int numberOfWritePoolThreads = randomIntBetween(10, 20); | ||
| double shardWriteLoad = randomDoubleBetween(0.0, 0.2, 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.
The only constraint for the shard write load in this test is that it is greater than zero so that the WriteLoadDecider considers it. So we could use a very small shard write load. I didn't originally realize the simulator factor when writing this test, clearly :) So I just picked a random value.
| */ | ||
| public void testHighNodeWriteLoadPreventsNewShardAllocation() { | ||
| int randomUtilizationThresholdPercent = randomIntBetween(50, 100); | ||
| int numberOfWritePoolThreads = randomIntBetween(10, 20); |
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.
Lowering the thread count might result in the shards being unable to fit on a single node, I expect. Not sure how much we care about realism. We could lower the shardWriteLoad to 0.001, to remove that concern -- and give the threshold randomization a bigger range of values.
…rdingly, ensure its non-zero
…ntDeciderIT # Conflicts: # muted-tests.yml
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.
Pull Request Overview
This PR fixes a flaky test in WriteLoadConstraintDeciderIT that was failing because the test didn't properly account for simulated utilization thresholds when moving shards. The fix ensures that node utilization calculations consider the additional load from all shards being moved, preventing test failures where shard movements would exceed the utilization threshold.
- Extracts utilization calculation logic into a reusable method in
ShardMovementWriteLoadSimulator - Updates the test to dynamically calculate maximum node utilization based on shard write load and thread pool configuration
- Removes the test from the muted tests list since it's now fixed
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| ShardMovementWriteLoadSimulator.java | Extracts utilization calculation into a public static method for reuse |
| WriteLoadConstraintDeciderIT.java | Updates test to properly calculate node utilization thresholds accounting for shard movement load |
| muted-tests.yml | Removes the now-fixed test from the muted tests list |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
.../java/org/elasticsearch/cluster/routing/allocation/decider/WriteLoadConstraintDeciderIT.java
Outdated
Show resolved
Hide resolved
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a HEAD=dc48fbbc74234e603da579b67c144a25d100b957 Branch=main
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a HEAD=dc48fbbc74234e603da579b67c144a25d100b957 Branch=main
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a HEAD=dc48fbbc74234e603da579b67c144a25d100b957 Branch=main
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a HEAD=dc48fbbc74234e603da579b67c144a25d100b957 Branch=main
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a HEAD=dc48fbbc74234e603da579b67c144a25d100b957 Branch=main
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a HEAD=dc48fbbc74234e603da579b67c144a25d100b957 Branch=main
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a HEAD=dc48fbbc74234e603da579b67c144a25d100b957 Branch=main
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a HEAD=dc48fbbc74234e603da579b67c144a25d100b957 Branch=main
Occasionally the
WriteLoadConstraintDeciderwould prevent shards moving to node 2 because those moves would exceed the utilisation thresholdI ran the test with all the extremes and it still works (i.e.
randomUtilizationThresholdPercent = 50,numberOfWritePoolThreads = 10,shardWriteLoad = 0.2,randomNumberOfShards = 20)Resolves: #133857