Closed gouhongshen closed 3 weeks ago
129: 64c128g 256 connection qps: 9w -> 4.5w
No plan yet
No plan yet
No plan yet
No plan yet
No plan yet
No plan yet
No plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
Not plan yet
need regression test, after https://github.com/matrixorigin/matrixone/pull/17863 merged.
replace:
- name: id
type: random
range: 1,100000
- name: i_id
type: sequence
start: 100001
step: 1
- name: tbx
type: random
range: 1,1
point_select_10_100000_prepare/replace.yaml 内容换成上面的就行
regression env:
case:
对比版本:
dcb07ac9e
(1.3.0 迭代)bca6edc16
test result:
- [point_select_1_10W_prepare]
- START : 2024-08-06 16:08:12
- END : 2024-08-06 16:23:24
- VUSER : 256
- TPS : 21452
- QPS : 21452
- SUCCESS : 19330279
- ERROR : 0
- RT_MAX : 1759
- RT_MIN : 0
- RT_AVG : 11.93
- SUC_RATE : 1.0
- EXP_RATE : 1.0
- RESULT : SUCCEED
+ [point_select_1_10W_prepare]
+ START : 2024-08-06 16:31:57
+ END : 2024-08-06 16:47:09
+ VUSER : 256
+ TPS : 30393
+ QPS : 30393
+ SUCCESS : 27358263
+ ERROR : 0
+ RT_MAX : 275
+ RT_MIN : 0
+ RT_AVG : 8.42
+ SUC_RATE : 1.0
+ EXP_RATE : 1.0
+ RESULT : SUCCEED
后续在 129 上面测一下
FIXED
Is there an existing issue for the same bug?
Branch Name
main, 1.1-dev
Commit ID
main eb6d613581d013c3bdbd9503bf82ccf9de254ac7
Other Environment Information
Actual Behavior
#
Expected Behavior
point select on pk of a small/empty table benchmarking on the 129-machine with 256 terminals.
the first minutes:
|
and the performance decreased:
|
why has the performance decreased? we can see along with the performance halved, the running threads also stay very low.
|
comparing the traces of them, found that the latter blocked on a chan:
that's why the running threads decreased,
the source code is located:
the tps can last longer by augmenting the
defaultQueueSize
.Steps to Reproduce
Additional information
No response