resourcecontrol: settle batched cop tasks' execution details#2029
Conversation
MakeResponseInfo read only the top-level execution details of a coprocessor response, but a batched request (StoreBatchTasks) answers several tasks in one response, each batch response carrying its own task's scan detail and process time. Those details were invisible to settlement, so resource groups and RU-based runaway detection undercounted the read bytes and CPU of every batched cop task. Sum every batch response's details (falling back to its data size when it carries no scan detail) into the response info. This corrects accounted RU upward for workloads that use store batching, to the value unbatched execution of the same tasks would have settled. Signed-off-by: 0xPoe <poe.liu@pm.me>
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus 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 |
What problem does this PR solve?
MakeResponseInforeads only the top-level execution details of a coprocessor response. A batched request (StoreBatchTasks, used by TiDB's store batching) answers several tasks in one response, and each batch response carries its own task's scan detail and process time. Those nested details are invisible to resource control settlement, so resource groups and RU-based runaway detection undercount the read bytes and KV CPU of every batched cop task.What is changed and how does it work?
ResponseInfo: read bytes from each batch response's scan detail (falling back to its data size when it carries no scan detail), and KV CPU from its time detail.scanDetailReadBytesand reuse it for the top-level and the batch responses' details.The accounting is shape-agnostic: it settles batch responses that carry data as well as ones that carry only execution details.
Note for reviewers: this corrects accounted RU upward for workloads using store batching, to the value unbatched execution of the same tasks would settle. If that increase needs gating (a config switch, or NextGen-only like the
TotalVersionsSizeprecedent), I am happy to add it.Tests
TestResponseInfoBatchedTaskscovering batch responses with data+details, details only, and data only.