SR单表并发查询性能下降

【详述】SR单表并发查询性能下降
【背景】做过哪些操作?
业务上对re_keyword_asin_info_ts_tag 表进行并发并发查询,查询的性能下降
单并发情况查询在 0.1s 内能返回,业务并发(50至100)提升后查询性能不稳定,查询响应时间在1-3s 左右

re_keyword_asin_info_ts_tag表结构:

CREATE TABLE re_keyword_asin_info_ts_tag (
country varchar(4) NOT NULL COMMENT “”,
asin varchar(16) NOT NULL COMMENT “”,
md5_id varchar(16) NOT NULL COMMENT “”,
keyword varchar(6553) NULL COMMENT “”,
group_ts varchar(1048576) NULL COMMENT “”
) ENGINE=OLAP
PRIMARY KEY(country, asin, md5_id)
COMMENT “OLAP”
DISTRIBUTED BY HASH(country, asin) BUCKETS 128
PROPERTIES (
“replication_num” = “1”,
“in_memory” = “false”,
“storage_format” = “DEFAULT”,
“enable_persistent_index” = “false”
);

查询语句:
SELECT re_keyword_asin_info_ts_tag.asin AS re_keyword_asin_info_ts_tag_asin
, re_keyword_asin_info_ts_tag.group_ts AS re_keyword_asin_info_ts_tag_group_ts
FROM re_keyword_asin_info_ts_tag
WHERE re_keyword_asin_info_ts_tag.country = ‘MX’ AND re_keyword_asin_info_ts_tag.keyword = ‘libreta norma’ AND re_keyword_asin_info_ts_tag.asin IN (‘B084MMDVBT’, ‘B0869KPY98’, ‘B082HPCXRY’, ‘B08C6BLKC2’, ‘B07LFHQTYW’, ‘B013WB7KGU’, ‘B08FKKJBBR’,‘B0778QTQ76’, ‘B08P5BYXQK’, ‘B073XBKH74’, ‘B08GFH7BCQ’, ‘B073X8VY9B’, ‘B08HS87GZN’, ‘B08N439LBD’, ‘B08GTJXTC6’, ‘B002HG0JDS’, ‘B08VF9B772’, ‘B08HSFWV5C’, ‘B08YWZZHN3’, ‘B08T8VP773’, ‘B092Q54MXR’, ‘B08X92PD5S’, ‘B08D6SYWTG’, ‘B08C75VZBD’, ‘B09ZTTL69Y’, ‘B07GZVB3MQ’, ‘B07HNK5QZC’, ‘B0040YNYSM’, ‘B00ZDH7B66’, ‘B00ZDHEQC8’, ‘B08TWK22TG’, ‘B08CTVSVBZ’, ‘6072110894’, ‘B08R7V62GV’, ‘B0B5W3HRNJ’, ‘B085ZZLC4G’, ‘B07DKSVV16’, ‘B07NVWQ2N3’, ‘B09N9WX5S6’, ‘B08C6C756F’, ‘B099RCFPY1’, ‘B0B9W132YP’, ‘B08HZFKDTX’, ‘B07V4KTGWS’, ‘B08V23P4HK’, ‘B00VXXLESK’, ‘B07PFHWSRB’, ‘B0969B84P6’, ‘B00ZDHC0EO’, ‘B07145M2T4’, ‘B09HR7S6Y6’, ‘B00P9U2BXU’, ‘B01NBDR4I3’, ‘B07PMNLVW5’, ‘B09T7CZ32X’, ‘1477029044’, ‘B09234RLFP’, ‘B084RMSG1Z’, ‘B07DKJCN4P’, ‘B07L445BHJ’)
;

【业务影响】
【StarRocks版本】2.3.4
【集群规模】2fe(2 follower)+ 12be
【机器信息】FE 16C 64G BE 32C/128G/万兆 SSD 3.5T*2
【联系方式】yangrong.juxfe@gmail.com
【附件】
非pipeline 模式下的profile
none_pipeline_profile.txt (36.5 KB)

pipeline模式下的profile
pipeline_profile.txt (25.3 KB)

CPU打满了吗,并发的时候

看监控CPU在80% 左右

可以主动把page cache打开试试,disable_storage_page_cache=false; 当前看卡在存储层的读上了

好的,我试一下看下

结果咋样,测试了吗

还没改参数测试,我们先在业务上把这个查询给优化掉了,通过跑批的方式去生成结果表再直接查结果表的数据
我晚上用命令跑下看下效果

刚刚测试过了,在be.conf开启disable_storage_page_cache=false; 后测了下,有一定效果,但是并发100左右还是很耗资源,由于这个数据的时效性要求不是很高,让业务先离线跑批生成结果表,然后再去查数据了。感谢大佬的支持。

对于这个表创建个索引会好很多,ASIN不是Key 吧

如果不是的话,asin 这上面建个BloomFilterIndex 试试

不是key的,我试一下建 BloomFilterIndex 再看下

创建bloomfilter index 后有效果吗。

是有效果的,看profile有命中 bloomfilter index
在单并发情况下比之前快一倍左右
50个并发左右查询也能在1s左右,也比之前快
但是开到100个并发查询的时间跟之前的是差不多了,在 2.4 - 2.6s左右

大佬有空可以帮忙再看下profile

1并发profile.txt (24.1 KB)
100并发profile.txt (24.0 KB)

看100 并发的profile还是pending的时间变长了,请问这部分是不是 cpu不够了,然后一直在等待照成的,这个表现在只搞了一个副本,搞到3个副本会不会更好一些呢?

CPU打满了吗?

应该可以更快,这个SQL应该是可以命中前缀索引的,不应该这么慢,需要看下是哪里的问题。这个表有多大?

你给我几个数据片断,我模拟下?

12个Be × 32C/128G?

Profile关了测试吧?

CPU在60 - 70% 左右
表的数据有 466532074
是12个BE 32C 128G的配置的
测试的时候profile关闭了

相关的数据片段在下面这个文件里面,请大佬查收:

data.txt (8.6 KB)