Starrocks基于主机和容器的读写测试

背景介绍

在云原生时代，存算分离架构显然已经是当下大数据架构的必备选型，但是在不同的虚拟化计算资源（主机、容器）之上，是否能有差异点以及对于不同服务的性能损耗程度如何？来判断应该在什么样的场景下选择什么样的资源配比将是存算分离引擎的调优手段之一。

本文的测试目的在于查看基于容器部署的Starrocks集群相较于主机部署的Starrocks集群，在数据读写上面是否有明显的差异点以及在集群配置CPU和内存资源配比上面找到较为合适的资源比例。

资源配置

Starorcks版本：3.2.0 存算分离，采用默认配置（下篇会基于不同特性开启下的性能差异对比）

机器资源：

机器类型：性能保障型X6 * 5台
机器规格：8C32G
云盘类型：ESSD_PL1

测试数据集：

社区提供的标准TPC-H数据集（100G、200G）

https://docs.starrocks.io/zh/docs/benchmarking/TPC-H_Benchmarking/

不同规格下数据写入速度

|---------------------------|------------|------------|
| | 8C32G | 16C64G |
| 100G 数据集 stream load 写入时间 | 9m42.586s | 10m21.843s |
| 200G 数据集 stream load 写入时间 | 20m32.206s | 20m12.313s |

数据读取测试

200G单并发主机和容器读取耗时对比

200G5并发主机和容器读取耗时对比

监控分析

200G tpch 数据 5 并发测试监控如下图所示，第一行是 16 核 64G 集群的 cpu 利用率、网络流量和内存使用监控，第二行是 8 核 32G 集群的监控

16 核 64G 集群的 cpu ：24 * 68% = 16.32
8 核 32G 集群的 cpu ：12 * 70% = 8.4

容器环境并发测试

内存瓶颈分析

在之前的测试中，当并发量到一定程度之后，就会出现部分查询语句失败的现象，而失败的原因全部都是超出了 BE 进程的内存限制，错误日志如下所示

现在以最容易失败的 Q9 为例，查看查询失败时 BE 节点的内存使用。其中 Q9 是一个涉及 6 张表 join 的复杂查询。

select
  nation,
  o_year,
  sum(amount) as sum_profit
from
  (
    select
    n_name as nation,
    extract(year from o_orderdate) as o_year,
    l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount
    from
    part,
    supplier,
    lineitem,
    partsupp,
    orders,
    nation
    where
    s_suppkey = l_suppkey
    and ps_suppkey = l_suppkey
    and ps_partkey = l_partkey
    and p_partkey = l_partkey
    and o_orderkey = l_orderkey
    and s_nationkey = n_nationkey
    and p_name like '%green%'
  ) as profit
group by
  nation,
  o_year
order by
  nation,
  o_year desc

以 Q9 的 30 并发为例，持续进行请求，下图是 BE 节点的 cpu & mem 监控截图，可以看出，内存一直在高点附近。

然后分析具体的内存占用，如下图所示，BE 进程的总内存 51G 已经到达了软限制，其中在这 51G 内存中，占用内存最多的是 query_pool 和 column_pool，分别代表 BE 查询层使用总内存和 column pool 内存大小，其中 column_pool 用于加速存储层数据读取的 Column Cache。很不幸的是，关于这两项内存占用，并没有相关配置可以进行调节。也就是说由于高并发导致的内存报错，只能通过修改 sql 语句和提升节点规格进行解决。

接下来再针对内存瓶颈，以 Q9 为例，进行一系列详细测试，测试结果如下

|--------|-----|------|------|------|
| | 5并发 | 10并发 | 20并发 | 25并发 |
| 8c32g | 成功 | 失败 | 失败 | 失败 |
| 8c64g | 成功 | 成功 | 失败 | 失败 |
| 16c64g | 成功 | 成功 | 成功 | 失败 |

其中，8c64g 的 20 并发是失败的，这一点值得讨论一下，因为 16c64g 的 20 并发是成功的，8c64g 的 20 并发错误日志和内存分析如下，可以看出错误原因发生了变化，这次是达到了 query pool 的内存限制，不过依旧无法通过调节配置进行解决

通过以上分析可以得出下述结论：

扩大 BE 节点内存可以缓解内存报错的现象
相同内存大小下，1:4 的 cpu 内存比要优于 1:8 的 cpu 内存比，不仅可以提升读性能，而且可以减少内存不足的风险

CPU瓶颈分析

该测试本想通过打满 8c64g 集群的 CPU，然后升级 cpu 规格来验证 cpu 的瓶颈。但是无论加多少并发，cpu 利用率始终很低，反而是升级 cpu 规格之后，利用率得到有效提升，最终的结论分析与上面的结论完全一致。

以 Q22 的 50 并发为例，测试结果记录如下。其中上面两张图是 8C64G 的 cpu 和 mem 监控截图，下面两张图是 16C64G 的 cpu 和 mem 监控截图。

本文总结

本文重点从基础性能方面对Starorcks进行了再不同规格、不同资源类型、不同并发下面的性能对比，从而也验证了在CPU和内存配比方面，1:4的配比是更为合适的资源配比，这对于Starorcks的资源选型方面提供了一定参考意义。

后面我们还有对于Starrocks不同特性开启之后，对于读写性能的提升，比如异步物化视图、查询队列、中间结果落盘、Pipeline Engine 、QueryCache等相关特性的提升来输出相关报告

如果想进一步交流的话，欢迎加我 V：kubedata

我们宗旨：分享创造价值、交流促进成长，欢迎关注：云原生大数据技术荟