-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
session, tikv: allocate task IDs for distsql requests #16520
Conversation
Signed-off-by: Yilin Chen <[email protected]>
Signed-off-by: Yilin Chen <[email protected]>
Signed-off-by: Yilin Chen <[email protected]>
Signed-off-by: Yilin Chen <[email protected]>
Should it be called SqlStatementId instead? |
Signed-off-by: Jay Lee <[email protected]>
Signed-off-by: Jay Lee <[email protected]>
Signed-off-by: Jay Lee <[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
Signed-off-by: Jay Lee <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #16520 +/- ##
===========================================
Coverage 80.0905% 80.0905%
===========================================
Files 510 510
Lines 139597 139597
===========================================
Hits 111804 111804
Misses 18823 18823
Partials 8970 8970 |
|
||
// AllocateTaskID allocates a new unique ID for a statement execution | ||
func AllocateTaskID() uint64 { | ||
return atomic.AddUint64(&taskIDAlloc, 1) |
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.
There is a chance that different tidb-server use the same task ID.
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.
TiKV will combine both start_ts
and task_id
into one.
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.
Got it, how about moving this calculation logic into the request sender side?
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.
TiDB's logic is too complicated, I'm not sure if start ts exists when task id is assigned.
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.
Can we use the statement idx, starts from 0 as the task id in the transaction?
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.
The original author also suggests to use the ID for tracing. I'm not sure if allocating as statement index will affect the purpose.
@@ -38,6 +39,13 @@ const ( | |||
WarnLevelNote = "Note" | |||
) | |||
|
|||
var taskIDAlloc uint64 |
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.
taskIDAlloc is a server-level variable here.
Can we define it as a session-level variable to reduce the contention on it?
/bench + sysbench |
/bench + tpcc |
1 similar comment
/bench + tpcc |
Benchmark Report
@@ Benchmark Diff @@
================================================================================
--- tidb: cd362cae723a1699cb6d3f77ed5b3600ac910c40
+++ tidb: 7aa06145f5eaa760c9e13d8caf0957e5df7caaac
tikv: cdca278ba7c2f631d5b3b5db08f1335dc7a89108
pd: 5a8ccb5b53e0a048146c019bfb48fd99c696cc6c
================================================================================
Measured tpmC (NewOrders): 7111.71 ± 1.41% (std=67.58), delta: 0.31% (p=0.756) |
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
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.
@sticnarf please resolve conflict.
Signed-off-by: Yilin Chen <[email protected]>
/run-all-tests |
/run-unit-test |
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
/run-all-tests |
@sticnarf merge failed. |
/run-all-tests |
@sticnarf merge failed. |
/run-all-tests |
Signed-off-by: sre-bot <[email protected]>
cherry pick to release-4.0 in PR #17155 |
Signed-off-by: Yilin Chen <[email protected]>
Does this PR need a release note? It seems not to affect users |
Currently the only effect is to help TiKV schedule requests better. I think you can decide whether to include the release note as you please. |
What problem does this PR solve?
Issue Number: close tikv/tikv#7484
Problem Summary:
Currently TiDB provides no information for TiKV that some group of requests belong to the same statement (task). So TiKV's unified read pool uses the start TS of the transaction as the task identifier . It's not suitable in all cases to use start ts as the task id for the unified read pool. For example, in the same transaction, a big query is executed and the following point selects are also downgraded.
What is changed and how it works?
What's Changed:
Currently in this PR, we only set task ids for distsql requests that can be run in transactions. For other distsql requests (like DDL reorg, analyze and checksum), the task id is not provided and TiKV still uses start_ts as task id. And TiKV uses random numbers as the task ids for point gets commands so this PR also does not set task ids for these requests.
Related changes
Check List
Tests
Side effects
Release note
Allocate task IDs for distsql requests to help TiKV schedule them better.