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

news2024/9/22 15:40:08

背景介绍

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

本文的测试目的在于查看基于容器部署的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

数据读取测试

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

2. 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 语句和提升节点规格进行解决。