StarRocks 2.2.2使用问题

💬 StarRocks 用户问答
#1

从1.18.1升级到2.2.2，升级完整体的感觉就是查询变得很慢，出现了老版本不存在的各种问题，烦请官方的同学帮忙看一下是哪里不对，下面列出了新老版本配置不同的地方：
1.18.1的配置：

基础环境里没有关闭swap交换分区，overcommit_memory不是1，是默认配置，getenforce没有关等等。基本上这些系统环境配置没有做任何改动，老环境是以root用户安装的，3fe+8be（fe和be混布）。

2.2.2的配置：
做了操作手册上的各种关于系统环境的设置，关闭swapp，关闭getenforce等等，用户是starrocks，新集群做了fe和be分离部署，老集群有三台fe和be是混布的，3fe+8be。安装了一个第三方的审计日志插件，做了资源隔离，新增了一个udf，后面为了排查是不是这些导致查询缓慢又相继去除了。

两个环境相同的地方是：
fragment instance数量相同，exec_mem_limit相同，表结构和数据量相同。

下面是使用过程中的一些问题，有些是bug，也有人反馈过。其中：
第2，3，4，5是老版本中不存在的问题。

1. insert into带上limit插入条数不正确

2. 非master节点执行如：show frontends，drop table 等语句报错：connection reset或failed to get master cient。select没有问题

目前通过重启master节点解决此问题

https://github.com/StarRocks/starrocks/pull/5656

3. spark connector读取sr数据偶发报错：scala.MatchError: 3002 (of class java.lang.Integer)

https://github.com/StarRocks/starrocks/issues/8324

4. Total size of single column exceed the limit of hash join

2.3版本已经放开这个限制了，当前join加shuffle

5. Pattern length exceeds limit

正则过长报错：Pattern length exceeds limit

6. udf执行效率不高

7. 无法查看资源隔离具体情况

现在2.2.2最主要的问题是查询很慢，还请官方的同学提供一些思路支持下，谢谢:pray:

#2

辛苦发下具体查询的profile吧

#3

profile (103.0 KB)

查询sql：select user_type,count(distinct user_id) from dwd.socialmedia_user_type group by user_type

查询表的表结构：
CREATE TABLE socialmedia_user_type (
platform_id int(11) NULL COMMENT “”,
user_id varchar(65533) NULL COMMENT “”,
user_type int(11) NULL COMMENT “”
) ENGINE=OLAP
UNIQUE KEY(platform_id, user_id)
COMMENT “OLAP”
DISTRIBUTED BY HASH(platform_id, user_id) BUCKETS 16
PROPERTIES (
“replication_num” = “3”,
“in_memory” = “false”,
“storage_format” = “DEFAULT”
);

#4

同一个sql开启pipeline比没开慢多了
select COUNT(1) from dwd.socialmedia_user_type;
没开启执行耗时：9s40ms
开启后执行耗时：39s443ms
两个profile如下：
关闭pipeline (62.0 KB)
开启pipeline (14.3 KB)

无论关没关pipeline，对于结果只有6000多万的数据，这个count的耗时也是太长了，超出可接受的范围了。

#5

2.2版本建议关掉pipeline，到2.3再使用呢。

1赞
#6

嗯，那我就关闭了吧，另外一个问题：关闭pipeline，count一个6000多万的数据，耗时9秒也太长了吧，能帮忙看一下吗？profile在上面。

#7

image
image1355×747 95.6 KB

scan时花费了太多的时间，方便发下表结构，以及show data from table_name的结果么？

#8

好的，表结构在前面的留言里发了，命令执行结果如下：

image
image757×289 37.1 KB

#9

想问一下，哪些系统环境层面的设置会导致查询慢？

#10

请尝试提高查询的并行度parallel_fragment_exec_instance_num。

#11

8be设置的BUCKETS 16比较低，建议提高。
分桶数量 = BE节点数量 * CPU 核数/2

#12

caused by compaction

#13

并行度已经是cpu核数的一半了，当前这个数值是20。

#14

但是数据量不太，只有5000千万，设太多的bucket就没有必要了吧。

#15

compaction查询的时候会做合并，那查询多次不是应该变快了嘛？

#16

现在的使用感觉就是明明集群资源挺空闲的，查询的数据量也不大，但是就是查询很慢。

#17

查询多次会变快，是由于数据都在内存。

#18

query_profile.txt (102.7 KB)
这是查询
select user_type,count(distinct user_id) from dwd.socialmedia_user_type group by user_type
的profile，对于一个5千万的表，这个时间有点长了。

#19 
set new_planner_agg_stage=3;

加了这个参数，速度快很多。

#20

new_planner_agg_stage
强制使用的聚合阶段数。
0 为自动选择，1~4 表示强制使用的聚合阶段数，3~4 只适用于单列 DISTINCT 场景。

京ICP备2022026421号-1