AggComputeTime时间过长

💬 StarRocks 用户问答 性能相关
#1

【详述】sql聚合操作时间过长
【背景】部分sql执行耗时非常久，但检测be节点负载并没有很高
【业务影响】
【StarRocks版本】2.0
【集群规模】2fe+13be
【机器信息】32核心128g内存
【附件】

  • fe.warn.log/be.warn.log/相应截图
  • 慢查询：
    • Profile信息
      profile (12.2 MB)
    • 并行度：/*+ SET_VAR(exec_mem_limit = 128719476736,query_timeout=10000000,batch_size=4096,parallel_fragment_exec_instance_num=40,new_planner_agg_stage=3) */
    • cbo是否开启：
      1
      1746×384 98.1 KB
    • be节点cpu和内存使用率截图
      2
      21796×418 182 KB
      3
      31274×612 141 KB

      实际集群上还存在别的任务在工作，所以内存cpu都存在一定波动
      表情况：
      4
      41558×876 398 KB

      按月分区，从2021年1月开始，每个分区下bucket80
#2

跟我的问题一样，sql执行前加个参数：set new_planner_agg_stage=3; 看看会不会好些。

#3

效果不是很好，还是容易超时，你使用的版本是多少呢？

#4

2.2.2的，我的情况和你相似，1.18.1的版本里不会这样，上了2.2.2之后有些sql执行变慢，但是集群负载并不高，单tablet数据量并不大，整个表数据量也不大，咨询说是出的plan不合理，说2.3解决了这个问题。

#5

针对小规模数据我测了一波貌似可以优化百分40左右，从20分钟优化到12分钟左右，但是针对那种scan超过150g的效果感觉还是不好

#6

看您的服务器内存128G，可以开启以下参数提高速度。
disable_storage_page_cache=false;
storage_page_cache_limit= 20G;

#7

麻烦查询一下
select first_label_id,count(*) from dws_dy_date_event group by first_label_id order by 2 desc limit 100;

#8

不知道您的建表语句，如果是这个SQL，那么以first_label_id作为DISTRIBUTED BY HASH(first_label_id) BUCKETS效果会好很多。

#9

这个是会有比较大的倾斜，业务原因，first_label_id的个数大概是1800个左右，表模型是更新模型，first_label_id只是其中一个维度字段，所以不能hash

#10

我看文档里这个默认就是开启的吧

#11

参数配置后依旧跑了很长时间，半个小时还是出不来结果

#12

1080 328362046
1146 137078464
1071 132770243
1127 107799090
1083 104944136
1077 98609359
1119 94567048
1081 86478846
1043 79045831
1046 73432651
1072 71377418
1123 68196988
1137 61578771
1143 60093177
1070 58301247
1142 54574339
1006 54196264
1106 53035512
1109 52531559
1104 50475660
1122 48967195
1148 44317435
1091 38764058
1133 38624840
1068 37009226
1079 36077268
1067 33752584
1144 33152587
1045 31487728
1049 31372148
1135 31222668
1139 31051372
1098 30176015
1065 30038403
1124 29804306
1140 29188752
1145 26627926
1069 26261272
1117 24635517
1121 24130823
1075 19911110
1062 19298213
1082 19290657
1138 17005784
1015 16775567
1129 16553160
1113 15874439
1114 15840986
1103 15831454
1051 15543500
1111 15457374
1073 15111431
1112 14839957
1130 14770855
1036 13949624
1055 13501193
1074 12365462
1048 12225034
1041 12118046
1061 11610590
1050 11301436
1120 10957032
1034 9873676
1115 9835666
1097 9724445
1134 9539344
1047 9482428
1059 9082039
1132 8695693
1093 8670481
1136 8613752
1100 8204214
1064 7509433
1003 7332564
1101 6645114
1092 6400112
6023156
1056 5880025
1090 5375215
1020 5025350
1044 4956770
1128 4946023
1126 4874307
1105 4422330
1149 4154521
1007 4106583
1099 3452053
1016 3296258
1076 3068664
1118 2816783
1131 2784197
1033 2737309
1088 2606359
1052 2374233
1008 2275924
1004 1744162
1021 1610481
1060 1358560
1032 1311896
1141 1288125

查询结果

#13

数据不均匀，SR是MPP架构，性能是取最慢的节点。

#14

有没有什么比较好的优化方案或者调整吗？

#15

尝试一下物化视图

#16

这个缓存的设置，官方文档是这样的：

image
image1071×214 33.1 KB

请问应该按什么单位设置？如果开启了缓存不设置，默认值是？

#17

您好，可以参考这块对page_cache的默认值。目前请按GB级别设置，关于配置项的单位后续我们会补全

#18
#19

bytes和GB都支持

#20

嗯，如果我开启了disable_storage_page_cache，不设置storage_page_cache_limit，这个值有默认值吗？有的话，这个值是多少，20g吗

京ICP备2022026421号-1