domain: batch handle the privilege reload event #59934
Conversation
ti-chi-bot
bot
added
release-note-none
|
Hi @tiancaiamao. Thanks for your PR. PRs from untrusted users cannot be marked as trusted with I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #59934 +/- ##
================================================
+ Coverage 72.9252% 75.1911% +2.2658%
================================================
Files 1701 1749 +48
Lines 469722 481030 +11308
================================================
+ Hits 342546 361692 +19146
+ Misses 106059 96770 -9289
- Partials 21117 22568 +1451
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
pkg/domain/domain.go
Outdated
| func ignoreBatchData(ch clientv3.WatchChan) { | ||
| ticker := time.NewTicker(5 * time.Millisecond) | ||
| defer ticker.Stop() | ||
| for i := 0; i < 1024; i++ { |
There was a problem hiding this comment.
Does 1024 here means maxBatchSize? Maybe use a const is more reasonable.
|
/retest |
|
@tiancaiamao: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/retest |
|
@tiancaiamao: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
| select { | ||
| case resp, ok := <-ch: | ||
| if !ok { | ||
| return event |
There was a problem hiding this comment.
Is it ok to rerun the event here？
The later use may be wrong？err := privReloadEvent(do.privHandle, &event)
There was a problem hiding this comment.
This function just focus on the batching functionality, and the first input event is a correct one passed by the caller.
The close of the channel will be handled by the reloadPrivilegeLoad instaed of this function.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Defined2014, wjhuang2016 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
ti-chi-bot
bot
added
lgtm
approved
and removed
needs-1-more-lgtm
[LGTM Timeline notifier]Timeline:
|
|
/retest |
|
@tiancaiamao: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/retest |
1 similar comment
|
/retest |
|
@Defined2014: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/retest |
|
@tiancaiamao: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
What problem does this PR solve?
Issue Number: close #59400
Problem Summary:
After a
NotifyPrivilegeUpdate(), the notification from etcd is laggy.When we're in a batch of privilege modification operations, the laggy event cause that even when the workload is done,
tidb still have a long period of time handling the laggy events.
This use 100% cpu (1 core) even there are no other events.
What changed and how does it work?
Wait for a while to get a batch of the laggy events, handle them together.
Check List
Tests
Before:
After:
As you can see, after the workload finish, the CPU drop to 0 immediately with this commit.
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.