[release-nextgen-202603] client: remove successful token wait logs#10997
Conversation
Successful token waits are expected while resource control throttles requests. Logging every wait over 10ms at WARN can flood TiDB logs under high QPS. Keep the existing histogram for observability and record the accumulated retry and reservation wait duration. Signed-off-by: lhy1024 <19542290+lhy1024@users.noreply.github.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## release-nextgen-202603 #10997 +/- ##
==========================================================
- Coverage 79.07% 79.02% -0.05%
==========================================================
Files 531 531
Lines 72298 72294 -4
==========================================================
- Hits 57168 57130 -38
- Misses 11093 11124 +31
- Partials 4037 4040 +3
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Signed-off-by: lhy1024 <19542290+lhy1024@users.noreply.github.com>
| if waitDuration > slowNotifyFilterDuration { | ||
| log.Warn("[resource group controller] waited for tokens", gc.logFields(waitDuration, nil)...) | ||
| } | ||
| gc.metrics.successfulRequestDuration.Observe(waitDuration.Seconds()) |
There was a problem hiding this comment.
Is this metric semantic change intentional? Previously, SuccessfulRequestDuration observed only d, which is the wait duration of the final successful reservation. After this change it observes waitDuration, which also includes the retry/backoff or reconfiguration wait accumulated before the final reservation. For requests that retry, this changes the existing histogram bucket/sum/quantile values, rather than only removing the successful-wait log. Could you confirm that recording the total accumulated wait in the existing metric is the expected behavior?
There was a problem hiding this comment.
Although I believe this change will make the monitoring more intuitive and easier to use, I’d still like to double-check, just in case.
There was a problem hiding this comment.
Good catch. Although recording the total accumulated wait was initially intentional, it is out of scope for this log-noise fix and would change existing histogram and dashboard values. I restored SuccessfulRequestDuration to observe only d, preserving its existing semantics. The final PR now only removes the two successful-wait WARN logs. Updated in 0f397e3.
Signed-off-by: lhy1024 <19542290+lhy1024@users.noreply.github.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bufferflies, JmPotato The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
[LGTM Timeline notifier]Timeline:
|
|
/retest |
3 similar comments
|
/retest |
|
/retest |
|
/retest |
What problem does this PR solve?
Issue Number: ref #10488
#10866 logs every successful client-side Resource Control token wait longer
than 10ms at WARN level. Successful waits are expected while requests are
throttled, so high-QPS workloads can produce excessive TiDB warning logs even
when all waits complete successfully.
What is changed and how does it work?
Check List
Tests
cd client && make gotest GOTEST_ARGS="./resource_group/controller/... -count=1"cd client && make staticRelated changes
Release note