startrocks多并发性能严重下降


这是查询资源的波动

这是分析简图耗时1s.txt (70.3 KB) 耗时4s.txt (70.9 KB)
背景:使用3.13版本的时候做并发测试,发现多并发情况下比单并发耗时大了几倍。
CREATE TABLE dws_defect_info (
PARTITION int(11) NOT NULL COMMENT “”,
lot_id varchar(65533) NOT NULL COMMENT “”,
wid varchar(65533) NOT NULL COMMENT “”,
did varchar(65533) NOT NULL COMMENT “”,
wafer_id varchar(65533) NULL COMMENT “”,
step_id varchar(65533) NULL COMMENT “”,
klf_file_timestamp datetime NULL COMMENT “”,
defect_id int(11) NULL COMMENT “”,
absolute_x decimal64(16, 3) NULL COMMENT “”,
absolute_y decimal64(16, 3) NULL COMMENT “”,
radius decimal64(16, 3) NULL COMMENT “”,
xrel decimal64(16, 3) NULL COMMENT “”,
yrel decimal64(16, 3) NULL COMMENT “”,
xindex int(11) NULL COMMENT “”,
yindex int(11) NULL COMMENT “”,
xsize decimal64(16, 3) NULL COMMENT “”,
ysize decimal64(16, 3) NULL COMMENT “”,
defect_area decimal64(16, 3) NULL COMMENT “”,
dsize decimal64(16, 3) NULL COMMENT “”,
test int(11) NULL COMMENT “”,
rough_bin int(11) NULL COMMENT “”,
manual_bin int(11) NULL COMMENT “”,
adc_bin int(11) NULL COMMENT “”,
manual_sem_bin int(11) NULL COMMENT “”,
auto_sem_bin int(11) NULL COMMENT “”,
ssa_micro_bin int(11) NULL COMMENT “”,
ssa_macro_bin int(11) NULL COMMENT “”,
best_bin int(11) NULL COMMENT “”,
last_bin int(11) NULL COMMENT “”,
fine_bin int(11) NULL COMMENT “”,
distance_to_center decimal64(16, 3) NULL COMMENT “”,
angle decimal64(16, 3) NULL COMMENT “”,
image_count int(11) NULL COMMENT “”,
image_paths varchar(65533) NULL COMMENT “”,
tiff_file_names varchar(65533) NULL COMMENT “”,
cluster_id int(11) NULL COMMENT “”,
defect_cluster_id int(11) NULL COMMENT “”,
repeater_id_tolerance1 int(11) NULL COMMENT “”,
repeater_id_tolerance2 int(11) NULL COMMENT “”,
repeater_id_tolerance3 int(11) NULL COMMENT “”,
repeater_id_tolerance4 int(11) NULL COMMENT “”,
repeater_id_tolerance5 int(11) NULL COMMENT “”,
inspection_tool varchar(65533) NULL COMMENT “”,
pre_relation_tolerance1 int(11) NULL COMMENT “”,
pre_relation_tolerance2 int(11) NULL COMMENT “”,
pre_relation_tolerance3 int(11) NULL COMMENT “”,
pre_relation_tolerance4 int(11) NULL COMMENT “”,
pre_relation_tolerance5 int(11) NULL COMMENT “”,
missing_defect_tolerance1 int(11) NULL COMMENT “”,
missing_defect_tolerance2 int(11) NULL COMMENT “”,
missing_defect_tolerance3 int(11) NULL COMMENT “”,
missing_defect_tolerance4 int(11) NULL COMMENT “”,
missing_defect_tolerance5 int(11) NULL COMMENT “”,
zone_index int(11) NULL COMMENT “”,
subdie_index varchar(65533) NULL COMMENT “”,
reticle_position_x decimal64(16, 3) NULL COMMENT “”,
reticle_position_y decimal64(16, 3) NULL COMMENT “”,
position_x int(11) NULL COMMENT “”,
position_y int(11) NULL COMMENT “”,
thumbnail_names varchar(65533) NULL COMMENT “”,
huge_defect int(11) NULL COMMENT “”,
remark varchar(65533) NULL COMMENT “”,
wafer_grid_number int(11) NULL COMMENT “”,
die_grid_number int(11) NULL COMMENT “”,
reticle_grid_number int(11) NULL COMMENT “”,
reclass_detail varchar(65533) NULL COMMENT “reclass详情”,
create_time datetime NULL COMMENT “”,
update_time datetime NULL COMMENT “”
) ENGINE=OLAP
PRIMARY KEY(PARTITION, lot_id, wid, did)
PARTITION BY (PARTITION)
DISTRIBUTED BY HASH(lot_id)
ORDER BY(PARTITION, lot_id, wid, did)
PROPERTIES (
“replication_num” = “3”,
“in_memory” = “false”,
“enable_persistent_index” = “true”,
“replicated_storage” = “true”,
“compression” = “LZ4”
);
这是建表语句

看grafana资源波动比较小,你们这个并发测试的时候是多少并发?

你好,并发数量是1:10的关系

我们是1个fe,4个be,其中fe、be是在一台物理机上。4个be分布在四台物理机上

压测的时候网络带宽的压力高吗?

这是十个并发时的带宽

这是一个并发时的带宽

看起来带宽不会死问题

看起来带宽不会是问题

而且我这边也是在物理机上使用client进行查询,应该不会有带宽的问题

四台机器都是在一个机房

这个带宽是说查询时be节点间会有数据传输,你们有机器的网络流量使用监控吗?
另外可以试试并发的时候调低下pipeline_dop,默认是0,核数的一半;可以调整为1试试

image
这是pipeline_dop=0的cpu峰值使用率,33.4,十个并发耗时3s左右,
image
这是pipeline_dop=1的cpu峰值使用率,19,十个并发耗时9s左右,

我这边暂时没有机器网络流量监控,我争取去弄一个过来。我们四台机器都是在同一个网段下同一个机房,应该不会因为网络传输的问题。

你好, dop =0 时, 10个并发下 4台BE的cpu 负载在30% 左右吗. 能再做两组测试吗?

  1. 尝试继续调大并发看下cpu能否压满和执行耗时
  2. 将array_agg换成其他聚合函数比如max, 再看下cpu利用率和执行耗时

好的,我中午之前把测试结果粘贴上来

你好,对于你所提的三个方向
1.网络流量方向,我让我们运维查过,接口流量远低于可达到的上限。
2.继续调大并发,根据反复的测试,在5个并发的时候各个be的cpu峰值(一瞬间,立马降下来)就在30%,10个并发在50%,有时候会到70%,25个并发,峰值基本都是在90%。内存变化不大。耗时也是从单并发的1.6s到2.2s到3.2s到6.4s。
3.函数换成max函数,单并发cpu 1%不到,同二进行测试,到25并发,cpu峰值9%。耗时也从0.2s到了0.6s,上述查看cpu利用率fe方法为top,因为监控看的没波动。
从上述三个测试,特别是第三个,来看,资源都没有问题,但是并发数增加,耗时就是成倍增加,25并发——max.txt (69.7 KB) 1并发——max.txt (69.2 KB)


补上监控图


补上be、fe安装机器的网络流量图

收到, 我们分析下.

希望尽快给出回复哈