Skip to content

Commit

Permalink
Merge branch 'feature/robus' of github.com:bufferflies/rfcs into feat…
Browse files Browse the repository at this point in the history
…ure/robus
  • Loading branch information
bufferflies committed Dec 29, 2021
2 parents 47488d5 + 7d1a4db commit eef4f8c
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions text/0085-Improve-the-robust-of-balance-scheduler.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Improve the robust of balance region scheduler
# Improve the robust of balance scheduler

- RFC PR: [https://github.com/tikv/rfcs/pull/85](https://github.com/tikv/rfcs/pull/83)
- Tracking Issue: [https://github.com/tikv/pd/issues/](https://github.com/tikv/pd/issues/4428)
Expand All @@ -13,7 +13,7 @@ We have observed many different situations when the region size is different. Th

1. Balance region scheduler picks source store in order of store's score, the lower store will be picked after the higher store has not met some filter or retry times exceed fixed value. If the count of placement rules or tikv is bigger, the lower store has less chance to balance like TiFlash.
2. splitting rocksDB and sending them by region leader will occupy cpu and io resources.
3. There are some factors that influence execution time of an operator such as region size, IO limit, CPU load. PD needs to be more flexible to manage operator's timeout threshold rather than not fixed value.
3. There are some factors that influence execution time of an operator such as region size, IO limit, cpu load. PD needs to be more flexible to manage operator's timeout threshold rather than not fixed value.
4. PD should know some global config about TiKV like `region-max-size`, `region-report-interval`. This config should synchronize with PD.

## Detailed design
Expand Down Expand Up @@ -44,7 +44,7 @@ It will be better if we can calculate every step expecting execute duration by m

![](https://latex.codecogs.com/gif.image?\dpi{200}&space;\bg_white&space;V=\frac{io_limit}{sending_{count}+receiving_{count}}=\frac{100Mb/s}{3+3}=16.7Mb/s\newline&space;T_{transfer}=\frac{10Gb}{16.7Mb/s}=598s\newline&space;T_{total}=T_{generator}+T_{transfer}+T_{apply})

The snapshot generator duration can ignore because it doesn't need to scan. The apply snapshot duration will finish in minute level if it needs to load hot buckets.
The snapshot generator duration can be ignored because it doesn't need to scan. The applying snapshot duration will finish at minute level if it needs to load hot buckets.

### Sync global config

Expand Down

0 comments on commit eef4f8c

Please sign in to comment.