Skip to content

Conversation

@nicktindall
Copy link
Contributor

@nicktindall nicktindall commented Sep 1, 2025

Occasionally the WriteLoadConstraintDecider would prevent shards moving to node 2 because those moves would exceed the utilisation threshold

I ran the test with all the extremes and it still works (i.e. randomUtilizationThresholdPercent = 50, numberOfWritePoolThreads = 10, shardWriteLoad = 0.2, randomNumberOfShards = 20)

Resolves: #133857

@nicktindall nicktindall added :Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) >test Issues or PRs that are addressing/adding tests labels Sep 1, 2025
@elasticsearchmachine elasticsearchmachine added v9.2.0 Team:Distributed Coordination Meta label for Distributed Coordination team labels Sep 1, 2025
@elasticsearchmachine
Copy link
Collaborator

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);
Copy link
Contributor Author

@nicktindall nicktindall Sep 1, 2025

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Member

@ywangd ywangd left a 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);
Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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,
Copy link
Member

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?

Copy link
Contributor Author

@nicktindall nicktindall Sep 2, 2025

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

  1. Create an index while cluster.routing.allocation.exclude._name = "secondDataNode, thirdDataNode" (all shards are assigned to firstDataNode)
  2. Mock the TransportNodeUsageStatsForThreadPoolsAction on 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)
  3. Refresh cluster info
  4. Update cluster.routing.allocation.exclude._name = "firstDataNode"
  5. Wait to see all the shards relocated to secondDataNode because first is excluded, and third is over the utilisation threshold.

So we have to have it over the threshold here.

Copy link
Contributor

@DiannaHohensee DiannaHohensee left a 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;
Copy link
Contributor

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.

Copy link
Contributor Author

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);
Copy link
Contributor

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);
Copy link
Contributor

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.

@nicktindall nicktindall changed the title Fix WriteLoadConstraintDeciderIT Account for simulated utilization threshold in WriteLoadConstraintDeciderIT Sep 3, 2025
@nicktindall nicktindall requested a review from Copilot September 3, 2025 01:57
Copy link
Contributor

Copilot AI left a 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.

@nicktindall nicktindall merged commit 068ca76 into elastic:main Sep 3, 2025
33 checks passed
@nicktindall nicktindall deleted the fix_WriteLoadConstraintDeciderIT branch September 3, 2025 03:11
phananh1010 added a commit to phananh1010/elasticsearch that referenced this pull request Sep 11, 2025
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a
HEAD=dc48fbbc74234e603da579b67c144a25d100b957
Branch=main
phananh1010 added a commit to phananh1010/elasticsearch that referenced this pull request Sep 12, 2025
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a
HEAD=dc48fbbc74234e603da579b67c144a25d100b957
Branch=main
phananh1010 added a commit to phananh1010/elasticsearch that referenced this pull request Sep 16, 2025
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a
HEAD=dc48fbbc74234e603da579b67c144a25d100b957
Branch=main
phananh1010 added a commit to phananh1010/elasticsearch that referenced this pull request Sep 16, 2025
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a
HEAD=dc48fbbc74234e603da579b67c144a25d100b957
Branch=main
phananh1010 added a commit to phananh1010/elasticsearch that referenced this pull request Sep 16, 2025
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a
HEAD=dc48fbbc74234e603da579b67c144a25d100b957
Branch=main
phananh1010 added a commit to phananh1010/elasticsearch that referenced this pull request Oct 9, 2025
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a
HEAD=dc48fbbc74234e603da579b67c144a25d100b957
Branch=main
phananh1010 added a commit to phananh1010/elasticsearch that referenced this pull request Oct 16, 2025
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a
HEAD=dc48fbbc74234e603da579b67c144a25d100b957
Branch=main
phananh1010 added a commit to phananh1010/elasticsearch that referenced this pull request Oct 24, 2025
BASE=5a4c3abb0e6c32c231da4a8377e4c7d75ee9379a
HEAD=dc48fbbc74234e603da579b67c144a25d100b957
Branch=main
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) Team:Distributed Coordination Meta label for Distributed Coordination team >test Issues or PRs that are addressing/adding tests v9.2.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[CI] WriteLoadConstraintDeciderIT testHighNodeWriteLoadPreventsNewShardAllocation failing

4 participants