Codecov Report

Merging #13896 (8c78a54) into dev (d772f24) will decrease coverage by 0.05%.
The diff coverage is 48.71%.

❗ Current head 8c78a54 differs from pull request most recent head 7d164f5. Consider uploading reports for the commit 7d164f5 to get more accurate results

@@             Coverage Diff              @@
##                dev   #13896      +/-   ##
============================================
- Coverage     38.91%   38.87%   -0.05%     
+ Complexity     4465     4453      -12     
============================================
  Files          1158     1158              
  Lines         42424    42414      -10     
  Branches       4772     4776       +4     
============================================
- Hits          16510    16488      -22     
- Misses        24097    24106       +9     
- Partials       1817     1820       +3     

... and 4 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Hi, @ruanwenjun , i just wonder why we use percentage representation? For me, physical memory is better.

Since the instance's memory/cpu might different, use percentage is more suitable, otherwise we need to set different config.

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

26.5% Coverage
0.0% Duplication

Since the instance's memory/cpu might different, use percentage is more suitable, otherwise we need to set different config.

If physical memory of different worker vary significantly, such as workerA has 8G memory and workerB has 64G, it's better to set different config, WDYT?

Anyway, we can still use different percentage to represent it if you think percentage is more intuitive :D

Since the instance's memory/cpu might different, use percentage is more suitable, otherwise we need to set different config.

If physical memory of different worker vary significantly, such as workerA has 8G memory and workerB has 64G, it's better to set different config, WDYT?

Anyway, we can still use different percentage to represent it if you think percentage is more intuitive :D

I think we may more concern about the percentage of usage.

Since the instance's memory/cpu might different, use percentage is more suitable, otherwise we need to set different config.

If physical memory of different worker vary significantly, such as workerA has 8G memory and workerB has 64G, it's better to set different config, WDYT?

Anyway, we can still use different percentage to represent it if you think percentage is more intuitive :D

Actually I think both make sense to me. May I ask whether it is possible to keep both of them and give users an option to configure whether by physical memory or by percentage?

Since the instance's memory/cpu might different, use percentage is more suitable, otherwise we need to set different config.

If physical memory of different worker vary significantly, such as workerA has 8G memory and workerB has 64G, it's better to set different config, WDYT?
Anyway, we can still use different percentage to represent it if you think percentage is more intuitive :D

Actually I think both make sense to me. May I ask whether it is possible to keep both of them and give users an option to configure whether by physical memory or by percentage?

This is possible, we can provide different strategy, e.g percentage, absolute value. This will need to change the whole config.

avoid-overload:
    strategy: Percentage
    max-memory-usage: 70%
    max-cpu-usage: 80%    
    # strategy: AbsoluteValue 
    # max-memory-usage: 6G
    # max-cpu-usage: 6C

If this is needed, I will improve this in the next PR.

This is possible, we can provide different strategy, e.g percentage, absolute value. This will need to change the whole config.

avoid-overload:
    strategy: Percentage
    max-memory-usage: 70%
    max-cpu-usage: 80%    
    # strategy: AbsoluteValue 
    # max-memory-usage: 6G
    # max-cpu-usage: 6C

If this is needed, I will improve this in the next PR.

Maybe we can simply provide two settings, if satisfy both, we consider the node is overload, like the memory usage is higher than 70% and reserved memory is less than 6G.

Since the instance's memory/cpu might different, use percentage is more suitable, otherwise we need to set different config.

If physical memory of different worker vary significantly, such as workerA has 8G memory and workerB has 64G, it's better to set different config, WDYT?
Anyway, we can still use different percentage to represent it if you think percentage is more intuitive :D

Actually I think both make sense to me. May I ask whether it is possible to keep both of them and give users an option to configure whether by physical memory or by percentage?

This is possible, we can provide different strategy, e.g percentage, absolute value. This will need to change the whole config.

avoid-overload:
    strategy: Percentage
    max-memory-usage: 70%
    max-cpu-usage: 80%    
    # strategy: AbsoluteValue 
    # max-memory-usage: 6G
    # max-cpu-usage: 6C

If this is needed, I will improve this in the next PR.

+1