SET enable_pipeline_engine=false; SET parallel_fragment_exec_instance_num=8; 查看tablet分布。 show data xxx; 说明 建议tablet大小在1 GB~10 GB。 查看建表。 通过Profile判断iotime。如果很大,可以删除一些不必要的索引,例如,删除建得比较多的bitmap索引。 查看表数据模型,选择合适的数据模型。例如,uniq ke...
parallel_fragment_exec_instance_num指定并行片段执行的实例数。默认为1.表示每个BE上fragment的实例数量,如果希望提升单个查询的性能,可以设置为BE的CPU核数的一半。query_mem_limit用于设置每个 BE 节点上查询的内存限制。以字节为单位。当查询使用的内存超过该限制时,查询将被终止。load_mem_limit各 BE 节点上单个...
调整并行度 通过setparallel_fragment_exec_instance_num=8; 增加并行度,提升计算资源利用率。 调整BE(Backend)节点的资源配置,避免资源竞争。 5、统计信息收集 定期收集表统计信息,帮助优化器生成高效执行计划:-- 手动收集统计信息ANALYZETABLEads_order COMPUTE STATISTICS; 6、资源隔离与优先级 为ADS 层查询分配独立...
我的意思是parallel_fragment_exec_instance_num参数没有生效,想了解一下这个参数是不是我测试所理解的意思呢?JiangLai 2022年03月8日 07:55 #4 您好,并不是调高了并行度,查询效率就一定会被提高,您可以通过查看profile中的OLAP_SCAN_NODE (id=x)来查看并行度是否生效,同id的表示同一个表的scan信息。我...
如果 BE 上还开启了并行度parallel_fragment_exec_instance_num(设置大于 1 时),则就可能需要拷贝更多份的右表数据了:BE 数量 * 并行度。从而,导致 JOIN 节点的右子节点的 EXCHANGE 节点花费很多的执行时间。 这种情况下,可以尝试采用shuffle join(在 SQL 中 join 修改成join [shuffle],即增加 shuffle 的 ...
结论4:测试 4 分析 fragment 1/2 实际并行度计算公式如下。适当增加 tablet 个数【partition、bucket】和 exec instance num 可以加快查询速度。此加速过程会作用于结论 1 中全部耗时点。 当tablet 个数【不含副本】小于 parallel_fragment_exec_instance_num * BE 个数时取 tablet 个数 ...
计算Fragment 的执行实例 该部分主要计算每个 Fragment 的执行实例数,StarRocks 在 BE 上执行资源和实例数相关,实例数越多,执行线程越多,实例数计算受以下一些参数影响: session 中的 parallel_exchange_instance_num session 中的 parallel_fragment_exec_instance_num ...
下图表示的是不合理的方式,右表是大表,采用的broadcast join方式,会将右表的数据拷贝BE数量*parallel_fragment_exec_instance_num(并行度)份,导致 JOIN 节点的右子节点的 EXCHANGE 节点花费很多的执行时间。 下图表示的是不合理的方式,两个表数据量相差比较大,现在采用的是shuffle join(两个孩子节点都是EXCHANGE NO...
提高StarRocks的查询并发(parallel_fragment_exec_instance_num) 提高单个查询内存限制(exec_mem_limit) 使用Prometheus+Grafana进行集群监控告警; 对查询历史进行分析,统计和监控慢SQL、大SQL,及时告警和优化。 权限与资源方面 细分账户,避免混用,实现更好的监控和维护,方便将大SQL、慢SQL准确定位用户; ...
例如数据是T+1更新,且单表数据量在百亿级别以上的场景(例如高维业务指标报表、Adhoc分析),我们构建了离线分析集群。通过提高StarRocks的查询并发(parallel_fragment_exec_instance_num)、单节点内存限制(exec_mem_limit)等对复杂查询友好的参数,提高集群的查询性能; ...