starrocks 2.5 insert导入队列,cpu资源使用限制有问题

【详述】starrocks 2.5 使用insert导入队列来限制执行时间长,耗费资源多的insert select语句。
实际情况没有达到预期,cpu使用率飙飙升至90%。
【业务影响】cpu使用率飙升
【StarRocks版本】例如:2.5.14
【集群规模】例如:3fe(1 follower+2observer)+ 5be
详细:
1.开启insert select 导入队列,参数如下:
SET GLOBAL enable_query_queue_load = true;
– 单个 BE 节点中并发查询上限
SET GLOBAL query_queue_concurrency_limit = 1000;
– 单个 BE 节点中内存使用百分比上限
SET GLOBAL query_queue_mem_used_pct_limit = 0.5;
– query_queue_cpu_used_permille_limit
SET GLOBAL query_queue_cpu_used_permille_limit = 200;

– 配置查询队列
SET GLOBAL query_queue_max_queued_queries = 1024;
SET GLOBAL query_queue_pending_timeout_second = 300;

2.在5分钟的压测中,每隔5s执行一次调度,每次调度同时提交5个并发 insert select的sql,同时执行,持续5分钟。
cpu使用率从10%一下,飙升到90%。
查看监控, insert select语句进入到了导入队列,但是cpu使用率没有控制住。
3.监控
导入队列:


be cpu使用

从监控看队列是生效了,不过cpu打满可能跟你的任务有关系,有可能单个任务就能打满,你可以试试1并发或者2并发,如果要想实现cpu隔离,建议使用资源隔离+队列

这个问题是因为 BE 汇报资源用量有延迟导致的

BE 周期性向 Leader 汇报 CPU、Memory、num_running_queries 使用量,汇报周期为 report_resource_usage_interval_ms,默认 1s。

所以,

  • 如果当前 CPU、Memory 用量没有超过阈值,瞬间来了很多查询,也都会放行。全部放行后,可能会在 BE 造成 OOM。

  • 无法应对短时间内到来的大量并发查询。短时间内到来大于 concurrency_limit (<3.1.4)的查询,也依然都会放行。

这个 BE 的汇报延迟,目前不太好解决。
或者可以升级到 >=3.1.4,使用 concurrency_limit 来限制。3.1.4 以后,concurrency_limit 是在 FE 自己统计的了,就没有汇报延迟的问题了

1赞

不是单个任务的问题,单个任务打不满。

可以每次加一个并发 往上慢慢测试下

1赞