StarRocks2.3.2 pipeline引擎性能问题

💬 StarRocks 用户问答
#69

会不会和pipeline_exec_thread_pool_thread_num配置有关，这个配置默认是cpu核数，是不是需要增加一下

#70

pipeline_exec_thread_pool_thread_num 不需要更改。

主要是二者的并行度不一样，并行度高会创建更多的任务来执行查询，每个查询又不是很大，所以高并发时 任务越多会导致任务的调度开销越大。

  • 关闭 pipeline 时的并行度 parallel_fragment_exec_instance_num 只有 1。
  • 开启 pipeline 时的并行度 pipeline_dop=0 会设置为核数一半（20）。

因此，尝试降低 pipeline_dop，慢查询就会有所降低。但是 pipeline 和非 pipeline 的一些执行逻辑不同，所以也不能降得太低。pipeline_dop=10 应该会比 pipeline_dop=5 的慢查询更少一些。

您最后再 set global pipeline_dop=10; set global is_report_success=true; set global pipeline_profile_level=1 试试看呢？就是 pipeline_dop=10，开启 profile、但是 profile_level=1。

#71

好的，我申请按您给的配置试一下

#72

image
image1842×685 59.7 KB

从我鼠标位置开始切换的，看上去切换后整体p99还是变慢了

#73

没找到明显变慢的profile，应该是整体都慢了一小点

#74

看了一波源码，不开启资源组时和开启资源组时的driver_queue是不一样的，因为StarRocks2.3.2有bug导致我没办法开启资源组，打算等国庆回来升级一下StarRocks2.3.3，然后打开资源组配置，使用work group driver queue，看看是不是能够解决现有的性能问题
我怀疑目前的性能问题在于高并发场景下，pipeline worker由于第一条数据来的慢暂时放回queue后，优先级设置的不合理，导致任务没有及时的再次启动，拖慢了查询的整体时间。

#75

QuerySharedDriverQueue
着重看了一下不开资源组时这个队列的代码
感觉问题就出在这
它将查询任务按照已经消耗时间分为了8个队列，并且在分配任务时，按照队列总消耗时间进行了加权分配，前一个队列的权重是后一个队列的1.2倍
分队阈值为0.2s, 0.6s, 1.2s, 2s, 3s, 4.2s, 5.6s, and 7.2s
在我的业务场景下，99%以上的查询在150ms以内，此时0.2s的队列总的执行时间会非常高。
此时如果来了一条慢查询，分配到了0.6s甚至更高的队列里，那么即使进行了1.2倍的加权，因为整个队列的执行时间较小，该任务的优先级也会非常高，因此导致了be倾注了所有资源到这条慢查询里面，导致查询时间短的普通查询，因为队列整体运行时间过长的原因，分配不到资源，变为慢查询。

#76

这种猜想和我实际遇到的慢查询都是扎堆一起出现的现象很一致。

#77

可能会有这个问题，但是可能性不是很大。Profile 中 ScheduleTime 是查询任务在就绪队列中的时间，如果因为调度优先级导致的饥饿问题，那么慢查询的 ScheduleTime 会特别长，但是实际 profile 中的 ScheduleTime 不并不是特别大。

#78

我在曾经调试Flink任务的时候也遇到过了这种5分钟粒度慢查询突刺的情况，不过是2.0版本时期的问题了，当时遇到的一个情况是，flink任务5分钟粒度的窗口，数据也就5分钟落盘一次
即使落盘的数据总量一样，但是当我调大StarRocks Sink算子的并行度30 -> 90 时，每整5分钟就是数据落盘的那一分钟会出现大量的慢查询语句，当时没有调查清楚原因，把并行度调整的改动回退后就没再出现这种情况了。

#79

profile (51.2 KB)
我在今天将集群版本升级到了2.3.3 开启了资源组配置。
性能还是不及预期
根据我对profile的分析，发现有些地方的数据不太合理，您能看看是什么问题吗

         - Aggr: 1s75ms
           - __MAX_OF_Aggr: 1s463ms
           - __MIN_OF_Aggr: 820.179ms
         - SegmentRead: 9.753ms
           - __MAX_OF_SegmentRead: 1s87ms
           - __MIN_OF_SegmentRead: 0ns

         - ScanTime: 13.517ms
           - __MAX_OF_ScanTime: 1s551ms
           - __MIN_OF_ScanTime: 1.774us

         - Union: 847.660ms
           - __MAX_OF_Union: 1s165ms
           - __MIN_OF_Union: 639.750ms

这几个地方的Max和Min值差距较大，也是整个profile首次出现了秒级别的时间，应该是整个sql的瓶颈所在，根据我的分析问题主要在SegmentRead/ScanTime里，由于某种原因，导致个别线程加载数据过于缓慢，影响了SQL的整体运行。

#80

我不知道应该调整哪些参数来解决这个问题

#81 
     - SegmentRead: 9.753ms
       - __MAX_OF_SegmentRead: 1s87ms
       - __MIN_OF_SegmentRead: 0ns

怀疑任务分配不均衡，把所有的Read操作都只交给了1个线程，其他的线程都空闲着
但是这条SQL的数据存储应该是没有严重的数据倾斜的，使用的time_at_5min分区，domain分桶，sql里in条件查询了大量的domain，因此应该会扫描单个分区的多个桶，不应该只有1个线程完成这些工作。

#82

StarRocks查询scan性能分析 可以参照这篇帖子做下数据倾斜的检查，方便的话也发一下explain costs + sql 的执行结果（以文本形式）

#83

好的，我粗略的看了一下，这个好像是旧版本的profile的分析文档，现在pipeline引擎的profile格式已经进行过变更了，也能用这篇文档来检测吗

#84

可以，该帖有介绍如何进行检测数据是否倾斜的方法和工具，和profile没有太大关系

#85

image
image818×60 3.77 KB

无法执行这个二进制文件

#86

image
权限应该没问题

#87

大佬后面怎么优化的，我们2.4.2版本，明细模型+物化视图的查询，关闭pipeline之后执行时间由11秒下降到4秒

#88

请问下最后是怎么解决的呢

京ICP备2022026421号-1