-
Notifications
You must be signed in to change notification settings - Fork 20
Conversation
Codecov Report
@@ Coverage Diff @@
## master #326 +/- ##
============================================
- Coverage 70.54% 69.57% -0.97%
- Complexity 2310 2371 +61
============================================
Files 307 318 +11
Lines 13686 14273 +587
Branches 1142 1199 +57
============================================
+ Hits 9655 9931 +276
- Misses 3669 3976 +307
- Partials 362 366 +4
Continue to review full report at Codecov.
|
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.
My two cents would be that we simplify the LevelAction classes further. I understand that once we have decided the level of jvm old-gen pressure we are in, the classes help us decide what we want to touch and in what order and how much of the knob we want to turn for it (decrease it in steps or wipe it clean).
It might make sense to define this in a yml and have just one level class that reads and takes actions. We may decide if the yml will be for code level config or something that operators can change but having it might make the logic more clear. What do you think ?
...istro/elasticsearch/performanceanalyzer/decisionmaker/actions/ModifyCacheCapacityAction.java
Outdated
Show resolved
Hide resolved
...istro/elasticsearch/performanceanalyzer/decisionmaker/actions/ModifyCacheCapacityAction.java
Outdated
Show resolved
Hide resolved
...on/opendistro/elasticsearch/performanceanalyzer/rca/store/collector/NodeConfigCacheUtil.java
Outdated
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelOneActionBuilder.java
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelOneActionBuilder.java
Outdated
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelTwoActionBuilder.java
Outdated
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelTwoActionBuilder.java
Outdated
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelTwoActionBuilder.java
Outdated
Show resolved
Hide resolved
...distro/elasticsearch/performanceanalyzer/decisionmaker/actions/ModifyCacheMaxSizeAction.java
Outdated
Show resolved
Hide resolved
...istro/elasticsearch/performanceanalyzer/decisionmaker/actions/ModifyQueueCapacityAction.java
Outdated
Show resolved
Hide resolved
...istro/elasticsearch/performanceanalyzer/decisionmaker/actions/ModifyQueueCapacityAction.java
Outdated
Show resolved
Hide resolved
.../elasticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/BaseActionBuilder.java
Outdated
Show resolved
Hide resolved
.../elasticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/BaseActionBuilder.java
Outdated
Show resolved
Hide resolved
.../elasticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/BaseActionBuilder.java
Outdated
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelOneActionBuilder.java
Show resolved
Hide resolved
...icsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelThreeActionBuilder.java
Outdated
Show resolved
Hide resolved
return LevelThreeActionBuilder.newBuilder(esNode, nodeConfigCache).build(); | ||
} | ||
else if (oldGenUsage >= OLD_GEN_THRESHOLD_LEVEL_TWO) { | ||
return LevelTwoActionBuilder.newBuilder(esNode, nodeConfigCache).build(); | ||
} | ||
else if (oldGenUsage >= OLD_GEN_THRESHOLD_LEVEL_ONE) { | ||
return LevelOneActionBuilder.newBuilder(esNode, nodeConfigCache).build(); |
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.
This is very neat for this particular use case, but these actionbuilders aren't reusable
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.
After rereading this my thoughts are the same. I don't understand what problem we were trying to solve by using the builder pattern here. We don't actually use the builders as legitimate builders, they're just wrappers around specific logic for generating a list of actions given a known bucket level. Why can't the static variables be held in this class with the List generated in actions() itself? Who would reuse these classes down the line?
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 moderately complex logic seems to live entirely in LevelTwoActionBuilder#actionPriorityForQueue(), but might not this just live in a function in this class?
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.
You are right, the complex logic right now only sit in Level two but as I mention above, we need to collect more data from experiment and then make changes based on that. So now level 1 & 3 are more like placeholder with very simple logics in it and each bucket in JVM decider can be evolved independently in the future.
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 agree with Sid, I don't really see a need for the common base class here. We have different strategies for each level that we want to be able to evolve independently. A simple interface might be enough.
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.
This base class approach was suggested by Joydeep because he though we can move those common code into base class. Yes, I agree with you. We don't necessarily need inheritance here and each level can evolve independently. Removed the base class
...distro/elasticsearch/performanceanalyzer/decisionmaker/actions/ModifyCacheMaxSizeAction.java
Outdated
Show resolved
Hide resolved
...istro/elasticsearch/performanceanalyzer/decisionmaker/actions/ModifyQueueCapacityAction.java
Outdated
Show resolved
Hide resolved
.../elasticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/BaseActionBuilder.java
Outdated
Show resolved
Hide resolved
.../elasticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/BaseActionBuilder.java
Outdated
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelOneActionBuilder.java
Outdated
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelTwoActionBuilder.java
Outdated
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelTwoActionBuilder.java
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelTwoActionBuilder.java
Outdated
Show resolved
Hide resolved
return LevelThreeActionBuilder.newBuilder(esNode, nodeConfigCache).build(); | ||
} | ||
else if (oldGenUsage >= OLD_GEN_THRESHOLD_LEVEL_TWO) { | ||
return LevelTwoActionBuilder.newBuilder(esNode, nodeConfigCache).build(); | ||
} | ||
else if (oldGenUsage >= OLD_GEN_THRESHOLD_LEVEL_ONE) { | ||
return LevelOneActionBuilder.newBuilder(esNode, nodeConfigCache).build(); |
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 agree with Sid, I don't really see a need for the common base class here. We have different strategies for each level that we want to be able to evolve independently. A simple interface might be enough.
...asticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/OldGenDecisionPolicy.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.
There's some conflict across PRs. Will wait till we consolidate before approving.
...distro/elasticsearch/performanceanalyzer/decisionmaker/actions/ModifyCacheMaxSizeAction.java
Outdated
Show resolved
Hide resolved
.../opendistro/elasticsearch/performanceanalyzer/decisionmaker/deciders/CacheHealthDecider.java
Outdated
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelOneActionBuilder.java
Outdated
Show resolved
Hide resolved
// TODO : read priority from yml if customer wants to override default ordering | ||
@Override | ||
protected void actionPriorityFilter() { | ||
actionFilter.put(ResourceEnum.FIELD_DATA_CACHE, 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.
I see. But from current changes, I don't see any action being added to actionFilter
as false
, so it seems like we just add actions to the actionFilter
map as true, and pick all of them in build
for each level*ActionBuilder
. What am i missing?
...mazon/opendistro/elasticsearch/performanceanalyzer/rca/configs/decider/CacheBoundConfig.java
Outdated
Show resolved
Hide resolved
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelTwoActionBuilder.java
Outdated
Show resolved
Hide resolved
...o/elasticsearch/performanceanalyzer/rca/configs/decider/jvm/LevelOneActionBuilderConfig.java
Outdated
Show resolved
Hide resolved
...o/elasticsearch/performanceanalyzer/rca/configs/decider/jvm/LevelTwoActionBuilderConfig.java
Outdated
Show resolved
Hide resolved
...o/elasticsearch/performanceanalyzer/rca/configs/decider/jvm/LevelTwoActionBuilderConfig.java
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.
Looks good. Will you add tests in a separate PR? If so, can you create an issue to track it?
public double getStepSize(ResourceEnum cacheType) { | ||
ThresholdConfig<Double> threshold = getThresholdConfig(cacheType); | ||
return (threshold.upperBound() - threshold.lowerBound()) / (double) getTotalStepCount(); | ||
} |
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.
Nice!
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.
+1
...sticsearch/performanceanalyzer/decisionmaker/deciders/jvm/old_gen/LevelTwoActionBuilder.java
Outdated
Show resolved
Hide resolved
// tie breaker | ||
else { | ||
if (workLoadTypeConfig.preferIngestOverSearch()) { | ||
actionFilter.put(ResourceEnum.WRITE_THREADPOOL, 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.
if ingest is preferable, we should downsize search queue, no?
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 catching this. Yes we should downsize search queue instead.
priorityOrder = new Config(PRIORITY_ORDER_CONFIG_NAME, configs.getValue(), | ||
DEFAULT_PRIORITY_ORDER, List.class); |
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.
Does this work? I was having trouble casting with generics
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.
yes, casting to a raw list still works. it can still pass the UTs that Adithya wrote which overrides the config settings in rca.conf and read this object to verify the changes.
private Predicate<List<String>> listValidator; | ||
|
||
public WorkLoadTypeConfig(NestedConfig configs) { | ||
listValidator = (list) -> { |
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.
Since there is only search and ingest (2 values), we can make this simpler by renaming the config. Instead of taking a list, we can do things like:
{ "decider-config-settings": {
"prefer-ingest-over-search": 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.
done. changed the config to
"workload-type": {
"prefer-ingest": true,
"prefer-search": false
},
This will allow user to not assign workload preference to any queue type
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 thanks for cleaning this up
public double getStepSize(ResourceEnum cacheType) { | ||
ThresholdConfig<Double> threshold = getThresholdConfig(cacheType); | ||
return (threshold.upperBound() - threshold.lowerBound()) / (double) getTotalStepCount(); | ||
} |
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.
+1
Issue #:
Description of changes:
Add JVM decider to RCA framework
Tests:
WIP
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.