There is a 1.63% performance regression in sysbench oltp_point_select after PR#69638
- Dominant language
- Go
- Stars
- 40.5k
- Forks
- 6.2k
- PR merge metrics
- PR metrics pending
Description
## Bug Report
### 1. Minimal reproduce step (Required)
1. Deploy a cluster with 3 TiDB and 3 TiKV instances.
2. Run benchmark sysbench (`oltp_point_select`).
3. Compare the TiDB commits below on the same cluster, keeping the TiKV and PD commits unchanged. Run each TiDB version twice.
### 2. What did you expect to see? (Required)
No performance regression.
### 3. What did you see instead (Required)
QPS regressed by approximately **1.63%** in sysbench (`oltp_point_select`) after #69638.
| description | tidb | tikv | pd | QPS avg (two runs) |
| --- | --- | --- | --- | --- |
| last success | pingcap/tidb@b36863fbed | tikv/tikv@446ad02ccb | tikv/pd@39b6220491 | 199383.34, 199891.79 |
| first regression | pingcap/tidb@e35ad93664 | tikv/tikv@446ad02ccb | tikv/pd@39b6220491 | 196243.28, 196530.23 |
The arithmetic mean of the two run-level QPS values decreased from **199637.56** (last success) to **196386.76** (first regression).
Regression percentage = `(last-success mean - first-regression mean) / last-success mean × 100` = **1.63%**. The reference here is the last-success commit, not the initial version used to start the bisect.
The bisect identified TiDB commit `e35ad93664`, introduced by #69638 ("*: enable global memory arbitration in priority mode by default"). TiKV and PD commits were unchanged between the two compared versions. A configuration-toggle verification has not yet been performed, so the specific runtime mechanism remains to be confirmed.
### 4. What is your TiDB version? (Required)
`9.0.0-beta.2.pre-2016-ge35ad93664` (pingcap/tidb@e35ad93664).
Contributor guide
Research direction
Start by reproducing sysbench oltp_point_select on the specified 3 TiDB/3 TiKV/PD cluster, comparing the last-success and first-regression commits while keeping TiKV and PD unchanged. Read PR #69638 and the global memory arbitration priority-mode changes, then perform the configuration-toggle verification mentioned in the report. Done means the regression mechanism is identified and the benchmark no longer shows the reported performance loss.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- databases, distributed-systems, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100