You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current hotspot identification mainly uses byte and key dimensions, which are not very fit for load requests with high CPU overhead but low hard disk overhead, we plan to add QPS dimension to better describe the distribution of CPU resources.
After adding more dimension in the statistics, the hotspot scheduler can extract to a multi-objective optimized problem. For example, we have a simple workload about the IndexLoopUp scenario:
As you can see in the picture, the IO is very imbalanced but the QPS is balanced. In the hot read scenario, we priority to choose the QPS dimension because this scenario is CPU bound in most cases. consider there are many cases and the priority dimension may be changed in different cases, we need to support some relative dimension statistics and make the dimension's priority or weight can be turned.
@nolouch on the monthly meeting@BusyJay said this feature is released in 5.2, is it true? I can see all tasks listed here is done. And if it is released, we can close this issue.
Also I'd like to know whether we write a design document for this task, or you think issue description already cover the design?
yes, it is already released in 5.2. but there are some problems left and need to be cleaned up, but we can close this one at first and create a new one for the remaining issues.
the design document may only acquire in the google document, cc @lhy1024 , cloud you add an RFC for this feature?
Background
The current hotspot identification mainly uses byte and key dimensions, which are not very fit for load requests with high CPU overhead but low hard disk overhead, we plan to add QPS dimension to better describe the distribution of CPU resources.
After adding more dimension in the statistics, the
hotspot scheduler
can extract to a multi-objective optimized problem. For example, we have a simple workload about theIndexLoopUp
scenario:As you can see in the picture, the IO is very imbalanced but the QPS is balanced. In the hot read scenario, we priority to choose the QPS dimension because this scenario is CPU bound in most cases. consider there are many cases and the priority dimension may be changed in different cases, we need to support some relative dimension statistics and make the dimension's priority or weight can be turned.
Development Task
Reformat hot statistic and hot scheduler
move-hot-read-peer
withmove-hot-read-leader
#3657[]float64
to represent hot peer loads #3591Introduce QPS statistic
Report QPS about each type of command in RegionHeartbeat and StoreHeartbeat
Report QPS about each type of command in RegionHeartbeat and StoreHeartbeat tikv#8157
Report QPS about each type of command in RegionHeartbeat and StoreHeartbeat #3695
Report QPS about each type of command in RegionHeartbeat and StoreHeartbeat pingcap/kvproto#638
Avoid merging regions with high QPS checker: avoid to merge region with high qps #3805
scheduler: use qps priority with multi priorities in hot region scheduler scheduler: use qps priority with multi priorities in hot region scheduler #3923
scheduler: compatibility about query info in hot scheduler scheduler: compatibility about query info in hot scheduler #3947
scheduler: use the store qps stats in the hot-write-leader-balance scheduler: use the store qps stats in the hot-write-leader-balance #3948
write qps
add more query kind in heartbeat pingcap/kvproto#794
add more query kind in heartbeat pingcap/kvproto#795
statistics: add more write query kind #4011
statistics: add more write query kind tikv#10786
Support multi priorities
Reduce different dim conflict
Misc
isHot
incheckHot
#3722Introduce the weight and priority
Advance
The text was updated successfully, but these errors were encountered: