You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@druid.apache.org by GitBox <gi...@apache.org> on 2021/11/15 03:09:11 UTC
[GitHub] [druid] hqx871 opened a new pull request #11691: Add lane strategy for mergeBuffer pool
hqx871 opened a new pull request #11691:
URL: https://github.com/apache/druid/pull/11691
<!-- Thanks for trying to help us make Apache Druid be the best it can be! Please fill out as much of the following information as is possible (where relevant, and remove it when irrelevant) to help make the intention and scope of this PR clear in order to ease review. -->
<!-- Please read the doc for contribution (https://github.com/apache/druid/blob/master/CONTRIBUTING.md) before making this PR. Also, once you open a PR, please _avoid using force pushes and rebasing_ since these make it difficult for reviewers to see what you've changed in response to their reviews. See [the 'If your pull request shows conflicts with master' section](https://github.com/apache/druid/blob/master/CONTRIBUTING.md#if-your-pull-request-shows-conflicts-with-master) for more details. -->
<!-- Replace XXXX with the id of the issue fixed in this PR. Remove this section if there is no corresponding issue. Don't reference the issue in the title of this pull-request. -->
<!-- If you are a committer, follow the PR action item checklist for committers:
https://github.com/apache/druid/blob/master/dev/committer-instructions.md#pr-and-issue-action-item-checklist-for-committers. -->
### Description
<!-- Describe the goal of this PR, what problem are you fixing. If there is a corresponding issue (referenced above), it's not necessary to repeat the description here, however, you may choose to keep one summary sentence. -->
<!-- Describe your patch: what did you change in code? How did you fix the problem? -->
<!-- If there are several relatively logically separate changes in this PR, create a mini-section for each of them. For example: -->
From the proposal [Dynamic prioritization and laning #6993] raised, there seems only the HTTP client connection limit from brokers to historicals has been solved. In this pr, I would like to add laning stragegy for the merge buffer pool on historicals and brokers.
<!--
In each section, please describe design decisions made, including:
- Choice of algorithms
- Behavioral aspects. What configuration values are acceptable? How are corner cases and error conditions handled, such as when there are insufficient resources?
- Class organization and design (how the logic is split between classes, inheritance, composition, design patterns)
- Method organization and design (how the logic is split between methods, parameters and return types)
- Naming (class, method, API, configuration, HTTP endpoint, names of emitted metrics)
-->
The idea is simple, I just limit each lane use only partial mergeBuffer pool according to the lane configuration. For example, if we use hilo laning strategy and maxLowPercent is 50%, then the low lane can only use 50% of the mergeBuffer pool, while the high can use all of it.
<!-- It's good to describe an alternative design (or mention an alternative name) for every design (or naming) decision point and compare the alternatives with the designs that you've implemented (or the names you've chosen) to highlight the advantages of the chosen designs and names. -->
I have come to this idea when I try to use the http connection lane strategy to protect our short running queries from long running queries, it helps but not enough. Without laning the mergeBuffers, we can only limit the http connections for the long running queries. However, if the long running connections are more than the mergeBuffers, the heavy queries will still block later group by queries, no matter they are short or long running, then blocked short running group by queries may use out of the connections, which surely block other timeseries and topn queries. On the other side, make the connections smaller than mergeBuffers may reject timeseries and topn queries directly, which do not need the mergeBuffer.
Add a laning strategy for mergeBuffer pool seems a better approach for me. I try to implement this feature and make some test on my mac. Here is result.
Test1. priority is same and without lane strategy.
|query_type|status|query_count|cost_mean|cost_std|cost_min|cost_max|
|--------|-------|-------|--------|-------|-------|-------|
|big_groupby | fail | 9 | 120086 | 119 | 120005 | 120248|
|big_groupby | success | 1 | 61732 | 0 | 61732 | 61732|
|medium_groupby | fail | 7 | 120110 | 127 | 120004 | 120248|
|medium_groupby | success | 3 | 102166 | 10275 | 95709 | 114016|
|small_groupby | fail | 17 | 120090 | 117 | 120002 | 120247|
|small_groupby | success | 83 | 35681 | 43282 | 5314 | 119543|
|small_timeseries | fail | 6 | 120245 | 1 | 120244 | 120247|
|small_timeseries | success | 94 | 4459 | 11714 | 253 | 56474|
Test2. heavy queries has low priority and only limit connections for heavy queries,
the connections is more than mergeBuffers
|query_type|status|query_count|cost_mean|cost_std|cost_min|cost_max|
|--------|-----------|-------|--------|-----------|-------|-------|
|big_groupby | fail | 7 | 120080 | 119 | 120003 | 120256|
|big_groupby | success | 3 | 100590 | 14663 | 83659 | 109058|
|medium_groupby | fail | 9 | 120117 | 131 | 120002 | 120256|
|medium_groupby | success | 1 | 83373 | 0 | 83373 | 83373|
|small_groupby | fail | 11 | 120120 | 129 | 120003 | 120257|
|small_groupby | success | 89 | 48602 | 49882 | 3069 | 119887|
|small_timeseries | success | 100 | 4205 | 15012 | 271 | 103966|
Test3. heavy queries has low priority and limit both connections and mergeBuffer capacity for heavy queries,
the connections is more than mergeBuffers
|query_type|status|query_count|cost_mean|cost_std|cost_min|cost_max|
|--------|-----------|-------|--------|-----------|-------|-------|
|big_groupby | fail | 9 | 120096 | 132 | 120002 | 120273|
|big_groupby | success | 1 | 106489 | 0 | 106489 | 106489|
|medium_groupby | fail | 6 | 120141 | 143 | 120007 | 120276|
|medium_groupby | success | 4 | 85114 | 34123 | 37190 | 113508|
|small_groupby | success | 100 | 34663 | 9976 | 2872 | 50173|
|small_timeseries | success | 100 | 2196 | 1494 | 368 | 7309|
As you can see, all of the small group by of test3 is succeed, while test1 and test2 have some failed small groupby queries, which are blocked by big grouby and medium groupby when requiring mergeBuffer. The cpu is also a problem as priority is same in test1, causing some timeseries queries failed.
So here comes my final approach to protect the short running queries from the long running queries, and make the throughout higher.
1. make the long running queries with low priority, to make they acquire the cpu after short running queries, especially when scheduling the processing thread.
2. put the long running queries to low lane, and always keep some mergeBuffers for short running queries.
Besides, I have run these tests many times on my mac book, the mergeBuffer laning strategy as test3 surely makes small group by queries succeed more. But it is not that obviously when comparing how many long running queries succeed and how much time the short and long cost. However, at most time, higher priority almost make short running queries finish faster and succeed more, and low parallelism may make more long running queries succeed as cpu competition is less.
Here is my test parameters:
1. I use the yellow_tripdata dataset to make this test and the cost unit is millisecond.
2. The big group by scan two year data, the medium group by scan one year data, and the small scan only one month data.
3. timeout is 120 seconds.
4. historical server has 2 merge buffers, 8 processing thread and 100 http thread.
5. connections between broker and historical server is 50
6. maxLowPercent is 50% when use hilo lane strategy, so there is only one merge buffer for heavy queries.
7. submit short running queries with 16 parallelism and 8 for long running queries
<!-- If there was a discussion of the design of the feature implemented in this PR elsewhere (e. g. a "Proposal" issue, any other issue, or a thread in the development mailing list), link to that discussion from this PR description and explain what have changed in your final design compared to your original proposal or the consensus version in the end of the discussion. If something hasn't changed since the original discussion, you can omit a detailed discussion of those aspects of the design here, perhaps apart from brief mentioning for the sake of readability of this PR description. -->
<!-- Some of the aspects mentioned above may be omitted for simple and small changes. -->
<hr>
##### Key changed/added classes in this PR
* `ResourceGroupScheduler`
* `SemaphoreResourceGroupScheduler`
* `DefaultBlockingPool`
* `ResourceScheduleStrategy`
* `LaningResourceScheduleStrategy`
* `ArbitraryResourceScheduleStrategy`
<hr>
<!-- Check the items by putting "x" in the brackets for the done things. Not all of these items apply to every PR. Remove the items which are not done or not relevant to the PR. None of the items from the checklist below are strictly necessary, but it would be very helpful if you at least self-review the PR. -->
This PR has:
- [x] added documentation for new or modified features or behaviors.
- [x] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for [code coverage](https://github.com/apache/druid/blob/master/dev/code-review/code-coverage.md) is met.
- [x] been tested in a test Druid cluster.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org
[GitHub] [druid] hqx871 closed pull request #11691: Add lane strategy for mergeBuffer pool
Posted by GitBox <gi...@apache.org>.
hqx871 closed pull request #11691:
URL: https://github.com/apache/druid/pull/11691
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org
[GitHub] [druid] hqx871 commented on pull request #11691: Add lane strategy for mergeBuffer pool
Posted by GitBox <gi...@apache.org>.
hqx871 commented on pull request #11691:
URL: https://github.com/apache/druid/pull/11691#issuecomment-1023038382
Fix conflict
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org
[GitHub] [druid] jihoonson commented on pull request #11691: Add lane strategy for mergeBuffer pool
Posted by GitBox <gi...@apache.org>.
jihoonson commented on pull request #11691:
URL: https://github.com/apache/druid/pull/11691#issuecomment-1022714987
Hi @hqx871, thank you for your contribution! The CI seems to have failed with some compilation issue. It will probably because of some changes made in the master branch. Can you please check and fix it?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org