Gbase8a 开启资源管理后sql性能变慢的问题

资源管理功能可以对SELECT和DML等受控SQL在运行过程中使用的CPU、内存、I/O和磁盘空间等资源进行合理管控，以达到资源合理利用，系统稳定性运行的要求。

前景：两套互为主备的集群（这里的互为主备是两个集群的数据都是从同一个点发来同时执行，两个集群间没有任何关联，主机配置集群配置都是一样的，集群版本：8.6.2.43），开发在执行脚本时发现同样的sql，在备用库的执行时间比在主库执行时间慢一倍左右，这是一条很简单的insert into xxx select xx，这条sql没有使用dblink，select的这部分中两个表join，关联列都是分布列，为何执行时间会如此之大？

首先排查备用集群是否是某个节点异常导致执行很差，观察集群sql执行时间，其他sql执行都很正常，那就开启集群日志level，观察慢节点

最慢的节点需要43s，最快的节点在express.log中也能算到，37s，整体时间都是平均的，慢的步骤主要是在sql执行阶段。

在主集群上也开level日志观察（这个是把日志开高了 这个开的15）

可以看到主集群执行时间都是非常快，那问题出现哪了？

我们开trace看下sql执行过程，首先是慢集群，直接看慢的步骤在哪里，是这个物化阶段。

 

在主集群也开启trace，对比观察                                         

其他步骤时间都是很快的，就差在了物化阶段，那物化阶段是怎么回事呢

Gbase8a 一条sql 的执行步骤是：

smart scan -> scan -> join -> aggregation -> sort -> materialization -> send result

GBase 8a为列存数据库，在返回多列结果集时，必须要将多个列文件的相同行，拼成一行结果集返回，聚集和排序操作的时候通常无需单独的物化步骤，物化在聚集和排序过程中已经完成。如果是包含嵌套子查询的复杂SQL，嵌套子查询从内至外递归执行，每一层的执行顺序与上述过程基本相同。

由此我们可以看到，主集群的物化阶段是边物化边发送结果，慢节点则是先物化完然后再一块发送结果，而且我们能看到快节点始终是使用的64并行度，慢节点在物化时使用了128并行度，那应该是并行度这块出了问题。

在慢节点手动设置并行度parallel_degree =64，重新执行sql，trace跟上面一样，在物化阶段还是使用了128并行度

嗷嗷…这个慢节点是开了资源管理的，设置参数task_max_parallel_degree=64 ，3s出结果，trace里的物化阶段也跟主集群的trace一样。

当并行度设置为0时，会进行自动评估，正常逻辑是：并行度为CPU核数，线程池为CPU核数*2这意味着，当有三个任务同时运行时，第三个任务就会串行，现在的版本还有bug，基本意味着第二个任务就是串行了。在物化阶段，当结果集 > 65536(一个dc的行数) * 可用并行度，进入边发送边物化过程。反之，则进入先物化后发送的过程。

另外，在设置此参数时，需要注意另一个参数max_thread_in_pool，此参数是整个集群的线程数，max_activetask*task_max_parallel_degree <gbase_parallel_max_thread_in_pool，我这里max_thread_in_pool=128，最后将并行度修改成4，任务数最多32个，超过之后，后来的sql都会串行，还是要根据实际业务需求去调整。

加油，打工人！