Starrocks性能优化

本文主要包括：

Starrocks性能优化

大SQL报内存不够

执行2亿的数据group by，报错：

ERROR 1064 (HY000): Memory of Queryac34fc2a-bfea-11ee-afb0-0cda411dfefe exceed limit. Pipeline Backend: 192.168.101.97, fragment: ac34fc2a-bfea-11ee-afb0-0cda411dff01 Used: 21478902080, Limit: 21474836480. Mem usage has exceed the limit of single query, You can change the limit by set session variable query_mem_limit

这里开启Starrocks的中间结果落盘：

在 BE 配置文件 be.conf 中指定落盘路径 spill_local_storage_dir，并重启集群使修改生效。
```
spill_local_storage_dir=/<dir_1>[;/<dir_2>]
```
在SQL执行之前，首先设置以下参数
```
SET enable_spill = true;
SET spill_mode = "auto";
set query_timeout = 600;
```
通过设置以上参数，大sql可以正常执行

all partitions have no load data

fe的日志里，存在大量的all partitions have no load data，这是因为，实时采集的时候，设置了每秒streamload一次。但是很多表其实是没有数据的
fe.warn.log日志：

2024-02-01 16:39:16,437 WARN (thrift-server-pool-285904|291996) [FrontendServiceImpl.loadTxnPrepare():1562] failed to prepare txn_id: 40582: all partitions have no load data
2024-02-01 16:39:16,450 WARN (thrift-server-pool-285910|292002) [FrontendServiceImpl.loadTxnRollback():1620] failed to rollback txn 40582: transaction not found: 40582
2024-02-01 16:39:35,889 WARN (thrift-server-pool-285970|292062) [FrontendServiceImpl.loadTxnPrepare():1562] failed to prepare txn_id: 40583: all partitions have no load data
2024-02-01 16:39:35,899 WARN (thrift-server-pool-285972|292064) [FrontendServiceImpl.loadTxnRollback():1620] failed to rollback txn 40583: transaction not found: 40583

可以在fe.conf里设置empty_load_as_error = false来规避

Query Profile 概述

通过将变量 enable_profile 设置为 true 以启用 Query Profile：

SET global enable_profile = true;

具体可以参考Query Profile 概述

提高Starrocks的写入性能

设置在be.conf里设置：flush_thread_num_per_store=8

Too many versions. tablet_id: 219542, version_count: 1001, limit: 1000

Caused by: com.starrocks.connector.flink.manager.StarRocksStreamLoadFailedException: Failed to flush data to StarRocks, Error response:
{“Status”:“Fail”,“BeginTxnTimeMs”:0,“Message”:“Too many versions. tablet_id: 219542, version_count: 1001, limit: 1000”,“NumberUnselectedRows”:0,“CommitAndPublishTimeMs”:0,
“Label”:“0e20db82-c001-4ba6-aa85-2bde651e2e17”,“LoadBytes”:889,“StreamLoadPutTimeMs”:5,“NumberTotalRows”:0,“WriteDataTimeMs”:86,“TxnId”:41058,“LoadTimeMs”:92,“ReadDataTimeMs”:0,“NumberLoadedRows”:0,“NumberFilteredRows”:0}

在be.conf 里设置以下参数

cumulative_compaction_num_threads_per_disk = 4
base_compaction_num_threads_per_disk = 2
cumulative_compaction_check_interval_seconds = 2
update_compaction_num_threads_per_disk = 2 #（该参数属于主键模型单独的compaction参数）

高并发执行越来越慢

执行sql时快时慢

具体表现在：
数据通过kafka_connetor导入到Starocks，刚开始查询速度很稳定，导入一段时间后，大概4个小时以后，再次查询相同的sql，每隔几秒钟，总有一个耗时比较长的。并且kafka里的数据后期数据量就很少了。
把实时采集的程序停止后，查询就又变稳定了

问题排查流程–导入

https://forum.mirrorship.cn/t/topic/1680

too many tablet version 问题解决方法

https://forum.mirrorship.cn/t/topic/1578

发生 “close index channel failed” 和 “too many tablet versions” 错误应该如何处理？

上述报错是因为导入频率太快，数据没能及时合并 (Compaction) ，从而导致版本数超过支持的最大未合并版本数。默认支持的最大未合并版本数为 1000。可以通过如下方法解决上述报错：

增大单次导入的数据量，降低导入频率。

修改 BE 配置文件 be.conf 中相关参数的配置，以加快 Compaction：
对于明细表、聚合表和更新表，可以适当调大 cumulative_compaction_num_threads_per_disk、base_compaction_num_threads_per_disk 和 cumulative_compaction_check_interval_seconds 的值。例如

cumulative_compaction_num_threads_per_disk = 4
base_compaction_num_threads_per_disk = 2
cumulative_compaction_check_interval_seconds = 2

对于主键表，可以适当调大 update_compaction_num_threads_per_disk 的值。适当调小 update_compaction_per_tablet_min_interval_seconds 的值。

update_compaction_num_threads_per_disk = 4
update_compaction_per_tablet_min_interval_seconds = 30

对于出现too many tablet versions的表，如何修复这个表？
现在是这个表无法读取