Introduce the resource control client#648
Conversation
| return &ResponseInfo{readBytes: readBytes, kvCPUMs: kvCPUMs} | ||
| } | ||
|
|
||
| func getKVCPUMs(detailsV2 *kvrpcpb.ExecDetailsV2, details *kvrpcpb.ExecDetails) uint64 { |
There was a problem hiding this comment.
I'm afraid wall time cpu is not so accurate here because it contains some wait time, so when the load is high, the same request will take longer to finish. @sticnarf Do you have any idea about this
There was a problem hiding this comment.
Truely. If we want to get the CPU time used by a request, process_wall_time_ms is inaccurate. It is reasonable to me to add another field for the real CPU cost.
There was a problem hiding this comment.
Is GetProcessWallTimeMs() - GetWaitWallTimeMs() good enough at present? @sticnarf
There was a problem hiding this comment.
No. For example, coprocessor may suspend a long request and execute other queries. The suspending time is counted in PorcessWallTimeMs but not counted in WaitWallTimeMs.
There was a problem hiding this comment.
Currently, the CPU precision does not need to be very high, Let's provide a better method later.
Signed-off-by: JmPotato <ghzpotato@gmail.com>
Signed-off-by: JmPotato <ghzpotato@gmail.com>
Signed-off-by: JmPotato <ghzpotato@gmail.com>
Signed-off-by: JmPotato <ghzpotato@gmail.com>
Signed-off-by: JmPotato <ghzpotato@gmail.com>
955da78 to
b570334
Compare
Signed-off-by: JmPotato <ghzpotato@gmail.com>
Signed-off-by: JmPotato <ghzpotato@gmail.com>
Signed-off-by: JmPotato <ghzpotato@gmail.com>
Signed-off-by: JmPotato <ghzpotato@gmail.com>
|
tikv/pd#5811 is ready. please continue the process |
Signed-off-by: JmPotato <ghzpotato@gmail.com>
Signed-off-by: JmPotato <ghzpotato@gmail.com>
Signed-off-by: JmPotato <ghzpotato@gmail.com>
Introduce the resource control client and its interceptor
Should merge after tikv/pd#5811.