-
Notifications
You must be signed in to change notification settings - Fork 228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
resource_control: add ru details in ExecDetails #1070
Conversation
@nolouch @bufferflies PTAL |
/cc @JmPotato As we add ru metrics into ExecDetails, seems we can let |
@@ -115,13 +116,14 @@ func buildResourceControlInterceptor( | |||
if reqInfo.Bypass() || resourceControlInterceptor.IsBackgroundRequest(ctx, resourceGroupName, req.RequestSource) { | |||
return next(target, req) | |||
} | |||
|
|||
consumption, penalty, priority, err := resourceControlInterceptor.OnRequestWait(ctx, resourceGroupName, reqInfo) | |||
consumption, penalty, waitDuration, priority, err := resourceControlInterceptor.OnRequestWait(ctx, resourceGroupName, reqInfo) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about use one struct ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if there is a best practice. The different between tuple and struct is not large, I see many other functions return multiple parameters.
if stmtExec := ctx.Value(util.ExecDetailsKey); stmtExec != nil { | ||
detail := stmtExec.(*util.ExecDetails) | ||
atomic.AddInt64(&detail.MilliRRU, int64(consumption.RRU*1000.0)) | ||
atomic.AddInt64(&detail.MilliRRU, int64(consumption.RRU*1000.0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why it needs to retry again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
retry what?
util/execdetails.go
Outdated
WaitRUDuration int64 | ||
// total read ans write ru in 1/1000 | ||
MilliRRU int64 | ||
MilliWRU int64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where does it use in this pr?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See: pingcap/tidb#49067
return | ||
} | ||
if stmtExec := ctx.Value(util.ExecDetailsKey); stmtExec != nil { | ||
detail := stmtExec.(*util.ExecDetails) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it maybe nil in some scenario?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. If the value exists, it should not be nil, otherwise the context value should not exist.
detail := stmtExec.(*util.ExecDetails) | ||
atomic.AddInt64(&detail.MilliRRU, int64(consumption.RRU*1000.0)) | ||
atomic.AddInt64(&detail.MilliWRU, int64(consumption.WRU*1000.0)) | ||
if waitDuration > time.Duration(0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what‘s the different if remove this condition? I think zero doesn't need to treat alone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the Duration is always 0 in OnResponse call, it's a very frequent value, so not need to do the atomic operation in this case. Though, the performance difference should be quite low.
Rest LGTM, you need to sync the upstream. |
util/execdetails.go
Outdated
@@ -329,6 +329,10 @@ type ExecDetails struct { | |||
BackoffDuration int64 | |||
WaitKVRespDuration int64 | |||
WaitPDRespDuration int64 | |||
WaitRUDuration int64 | |||
// total read ans write ru in 1/1000 | |||
MilliRRU int64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is Milli
for precision? I think it correspond to milliseconds
, but this is multiplied by 1000.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe RRUx1000
:).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. naming similar to millisecond, not sure if it is the correct naming.
Signed-off-by: glorv <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
* collecting the RU information by pasing point through context.Value (tikv#1032) Signed-off-by: zzm <[email protected]> * add ruWaitDuration to RUDetails and update pd-client Signed-off-by: glorv <[email protected]> --------- Signed-off-by: zzm <[email protected]> Signed-off-by: glorv <[email protected]> Co-authored-by: zzm <[email protected]> Signed-off-by: iosmanthus <[email protected]>
* collecting the RU information by pasing point through context.Value (tikv#1032) Signed-off-by: zzm <[email protected]> * add ruWaitDuration to RUDetails and update pd-client Signed-off-by: glorv <[email protected]> --------- Signed-off-by: zzm <[email protected]> Signed-off-by: glorv <[email protected]> Co-authored-by: zzm <[email protected]>
…#1151) * resource_control: add ru details in ExecDetails (#1070) * collecting the RU information by pasing point through context.Value (#1032) Signed-off-by: zzm <[email protected]> * add ruWaitDuration to RUDetails and update pd-client Signed-off-by: glorv <[email protected]> --------- Signed-off-by: zzm <[email protected]> Signed-off-by: glorv <[email protected]> Co-authored-by: zzm <[email protected]> * use latest pd-client of release-7.5 Signed-off-by: nolouch <[email protected]> --------- Signed-off-by: zzm <[email protected]> Signed-off-by: glorv <[email protected]> Signed-off-by: nolouch <[email protected]> Co-authored-by: glorv <[email protected]> Co-authored-by: zzm <[email protected]>
* collecting the RU information by pasing point through context.Value (tikv#1032) Signed-off-by: zzm <[email protected]> * add ruWaitDuration to RUDetails and update pd-client Signed-off-by: glorv <[email protected]> --------- Signed-off-by: zzm <[email protected]> Signed-off-by: glorv <[email protected]> Co-authored-by: zzm <[email protected]> Signed-off-by: iosmanthus <[email protected]>
* collecting the RU information by pasing point through context.Value (tikv#1032) Signed-off-by: zzm <[email protected]> * add ruWaitDuration to RUDetails and update pd-client Signed-off-by: glorv <[email protected]> --------- Signed-off-by: zzm <[email protected]> Signed-off-by: glorv <[email protected]> Co-authored-by: zzm <[email protected]> Signed-off-by: iosmanthus <[email protected]>
* collecting the RU information by pasing point through context.Value (tikv#1032) Signed-off-by: zzm <[email protected]> * add ruWaitDuration to RUDetails and update pd-client Signed-off-by: glorv <[email protected]> --------- Signed-off-by: zzm <[email protected]> Signed-off-by: glorv <[email protected]> Co-authored-by: zzm <[email protected]> Signed-off-by: iosmanthus <[email protected]>
) (tikv#1151) * resource_control: add ru details in ExecDetails (tikv#1070) * collecting the RU information by pasing point through context.Value (tikv#1032) Signed-off-by: zzm <[email protected]> * add ruWaitDuration to RUDetails and update pd-client Signed-off-by: glorv <[email protected]> --------- Signed-off-by: zzm <[email protected]> Signed-off-by: glorv <[email protected]> Co-authored-by: zzm <[email protected]> * use latest pd-client of release-7.5 Signed-off-by: nolouch <[email protected]> --------- Signed-off-by: zzm <[email protected]> Signed-off-by: glorv <[email protected]> Signed-off-by: nolouch <[email protected]> Co-authored-by: glorv <[email protected]> Co-authored-by: zzm <[email protected]> Signed-off-by: zzm <[email protected]>
* collecting the RU information by pasing point through context.Value (tikv#1032) Signed-off-by: zzm <[email protected]> * add ruWaitDuration to RUDetails and update pd-client Signed-off-by: glorv <[email protected]> --------- Signed-off-by: zzm <[email protected]> Signed-off-by: glorv <[email protected]> Co-authored-by: zzm <[email protected]> Signed-off-by: iosmanthus <[email protected]> Signed-off-by: zzm <[email protected]>
* collecting the RU information by pasing point through context.Value (tikv#1032) Signed-off-by: zzm <[email protected]> * add ruWaitDuration to RUDetails and update pd-client Signed-off-by: glorv <[email protected]> --------- Signed-off-by: zzm <[email protected]> Signed-off-by: glorv <[email protected]> Co-authored-by: zzm <[email protected]> Signed-off-by: iosmanthus <[email protected]>
cherry-pick #1032 to master and add
RUWaitDuration
to RUDetails. RUDetails is used in recording executing log and slow log in tidb.