-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Optimize DataTierAllocationDecider Further #78235
Optimize DataTierAllocationDecider Further #78235
Conversation
This decider is still by far the most expensive component of reroute operations. Optimizing away some more costly allocations and slow stream loops.
Pinging @elastic/es-data-management (Team:Data Management) |
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.
LGTM, except for the regexp use.
@@ -90,8 +91,7 @@ public void validate(String value, Map<Setting<?>, Object> settings, boolean exi | |||
"] tier preference may be used for partial searchable snapshots (got: [" + value + "])"); | |||
} | |||
} else { | |||
String[] split = value.split(","); | |||
if (Arrays.stream(split).anyMatch(DATA_FROZEN::equals)) { | |||
if (FROZEN_TIER_PATTERN.matcher(value).find()) { |
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 am not really sure about this bit, might run faster, might not?
Perhaps we can add a test validating that just doing value.indexOf(DATA_FROZEN)
is safe, i.e., that there are no other tiers starting with DATA_FROZEN
?
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.
Jup see d62ad36 that should be much faster and is more fun to read as well :)
Thanks Henning! |
This decider is still by far the most expensive component of reroute operations. Optimizing away some more costly allocations and slow stream loops.
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 know this is already merged, but I left a comment about behavior that this changes
.../main/java/org/elasticsearch/xpack/cluster/routing/allocation/DataTierAllocationDecider.java
Show resolved
Hide resolved
My other concern about this is that without any code comments about why these changes were made, we run the risk of accidentally undoing these changes in a subsequent PR. (something like "oh, I like streams, I'll use those rather than this old |
This decider is still by far the most expensive component of reroute operations on very large clusters.
Optimizing away some more costly allocations and slow stream loops.