【TiDB v7.1.0】资源管控调研及评测

作者： angryart 原文来源：https://tidb.net/blog/ad24240a

多租户是什么

有语云，食在广州，玩在杭州，死在柳州，广东人除了天上飞的飞机不吃，地上走的坦克不吃，其它的什么都吃，广州作为省市，吃方面更为极致，它汇集了广府、潮汕、客家的各种特色和口味。一年一度的美食盛宴，广州为四方来客准备了万人宴席，但是万人宴席如何面对成万上亿的中国吃货呢？

一个笨方法是先入先出，通过先入者得到座席，吃完后先出去的方式，但是很快就出现问题 。有些客人是长服务，他提前就点了一堆的东西 ，结果只分配了他们 5 个座席，他们只能默默的吃，占住位置不释放。另外资源分配也有类似的问题，最后发生所有的座席满员，其它的人只能等待。可怜短服务需求的人，有些人不远万里过来只为吃一粒牛肉丸，有些人只为了吃一个叉烧包。因为愚蠢程序的设计，结果等着等着，活生生饿死，造成系统大面积瘫痪。

解决问题之道 是加强资源调度管理，IT 界引引入了多租户的管理方法。业界有两个渐为成熟的管理方法， 一个是 capacity 调度方法 ，一个是 fair 调度方法，capacity 把资源按比例分配给各个队列，队列下面再划分二层队列，并添加严格的管理制度防止用户或队列独占资源，而 fair 则是按照公平的原则把资源分给各资源组，力保每一个用户都在进行中。

通俗的话表达，capacity Scheduler 就是根据资源适配业务，按比例划分长服务 50%、中服务 30%、短服务 20%，这样长服务得到更多资源吃饭，吃完就走，短服务因为是吃一碗糖水，占平台的资源不多，吃完就走。fair Scheduler 则按标签权重划分划分，而且在算法上会关怀短服务以及那些优先高的任务，这样它们快速完成任务资源释放，后面平台可以服务更多的用户。

数据库的多租户

业界应用实践 capacity Scheduler 和 fair Scheduler 的产品有 YARN，YARN 是 hadoop2 推出来的资源管理调度框架，沉浸多年，技术上已经非常成熟，估计 OceanBase 的开发就是借鉴了很多 YARN 的特性，OceanBase 开源后本身就有多租户功能，创建一段 OB 多租户示例如下

创建15个CPU，3G内存的资源单位unitfishobclient [oceanbase]> CREATE RESOURCE UNIT unitfish MAX_CPU 15, MEMORY_SIZE '3G', MAX_IOPS 1280,LOG_DISK_SIZE '10G', MIN_IOPS=1024;Query OK, 0 rows affected (0.015 sec)​资源单位unitfish绑定资源池poolfish​obclient [oceanbase]> CREATE RESOURCE POOL poolfish UNIT = 'unitfish', UNIT_NUM = 1,ZONE_LIST = ('zone1');Query OK, 0 rows affected (0.025 sec)​资源池poolfish绑定租户tenantfishobclient [oceanbase]> create tenant tenantfish resource_pool_list=('poolfish'), charset=utf8mb4, replica_num=3, zone_list('zone1'), primary_zone=RANDOM, locality='F@zone1' set variables ob_compatibility_mode='mysql', ob_tcp_invited_nodes='%';Query OK, 0 rows affected (24.164 sec)

OceanBase 的资源管控是三步走的过程。

第一步定义资源单元，资元单元声明里面最少可以占用多少资源，最多可以占用多少资源。

第二步声明资源池，指定资源单元 以及相关 单元数量，两者乘积就是资源池所有的性能。

第三步就是资源池绑定租户，并指定租户与数据副本的映射关系。

OceanBase 资源管控策略意图很明显，第一步先声明一个细粒度的资源，足够小以后可以按照业务的需求个性化组装， 第二步可以组合成功的资源规格可以满足业务的需求，一般这是完成与业务绑定了。

OceanBase 的资源管控策略与 capacity Scheduler、fair Scheduler 不一样， TiDB 的创新方式也与 OceanBase 的不一样。

TiDB 的资源管控核心理念是 RU,Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的单位, 目前包括 CPU、IOPS 和 IO 带宽三个指标。这三个指标的消耗会按照一定的比例统一到 RU 单位上。

区别于 OB 的细粒度管控方式，TiDB 通过 PRIORITY 和 BURSTABLE 对资源争夺进行管控，如果发生资源恶性竞争，优先满足 PRIORITY 高的资源组，如果发生资源闲置，打上 BURSTABLE 的资源组允许当它处理空闲时其它资源组使用它的资源。

TiDB 的资源组除了能够绑定租户，也能绑定会话，语句。不过，笔者认为最有特色的是根据实际负载估算容量。

capacity Scheduler 的资源管控策略基于集群硬件部署按照比例的方式笼切去切分，OceanBase 的资源管控策略则是基于硬件部署的精确个数去划分，前提是必须知道服务器有多少个 CPU，CPU 是什么规格属性，才能灵活分配资源，属于硬件配置校准的方式。

现在 TiDB 的根据实际负载估算容量 可以忽略服务器软硬件的情况，通过业务负载知道预判该租户可以使用多少资源。技术原理与 openGauss 的 AI4DB 的类似，openGauss 实现数据库自治运维管理，通过采集 CPU、内存、硬盘的工作指标状态，保存在时序 promethous 里面，定期汇聚合并，通过 dbmind 分析数据库的运维参数，从而得出哪些参数需要调整优化。

与 openGauss 不同，TiDB 不需要额外安装组件、服务、时序数据库，这个比较省心。不过启用根据实际负载估算容量会占用 TiDB 额外的计算消耗。

实验环境

以下创建三个资源组，其中 RG1 是 100，RG2 是 500，RG3 是 2000，如下。选 用 sysbench 以及 chbenchmark 做压力均衡的测试。

​CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 100 ;CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 500;CREATE RESOURCE GROUP IF NOT EXISTS rg3 RU_PER_SEC = 2000 PRIORITY = HIGH BURSTABLE;​CREATE USER 'sysbench1'@'%' IDENTIFIED BY '123456' RESOURCE GROUP rg1;CREATE USER 'sysbench2'@'%' IDENTIFIED BY '123456' RESOURCE GROUP rg2;CREATE USER 'chbench1'@'%' IDENTIFIED BY '123456' RESOURCE GROUP rg3;​#  sysbench1绑定rg1#  sysbench2绑定rg2 #  chbench1绑定rg3 ​​grant all privileges on   chbenchmark.*  to  chbench1;grant all privileges on   chbenchmark.*  to  sysbench1;grant all privileges on   chbenchmark.*  to  sysbench2;​

测试资源隔离

以 sysbench 做基准，分别以 sysbench1 和 sysbench2 执行相同一个任务，如下。期望 500RU 的 sysbench2 会比 100RU 的 sysbench1 快。

sysbench   /usr/share/sysbench/oltp_read_only.lua  --mysql-user=sysbench1 --mysql-password='123456' --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run​sysbench   /usr/share/sysbench/oltp_read_only.lua  --mysql-user=sysbench2 --mysql-password='123456' --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run​sysbench1的结果如下​[ 10s ] thds: 4 tps: 23.49 qps: 378.07 (r/w/o: 330.69/0.00/47.38) lat (ms,95%): 204.11 err/s: 0.00 reconn/s: 0.00[ 20s ] thds: 4 tps: 19.90 qps: 319.62 (r/w/o: 279.82/0.00/39.80) lat (ms,95%): 211.60 err/s: 0.00 reconn/s: 0.00[ 30s ] thds: 4 tps: 19.80 qps: 316.92 (r/w/o: 277.32/0.00/39.60) lat (ms,95%): 211.60 err/s: 0.00 reconn/s: 0.00​​sysbecn2的结果如下​[ 10s ] thds: 4 tps: 110.17 qps: 1766.70 (r/w/o: 1545.95/0.00/220.75) lat (ms,95%): 95.81 err/s: 0.00 reconn/s: 0.00[ 20s ] thds: 4 tps: 100.80 qps: 1613.18 (r/w/o: 1411.57/0.00/201.61) lat (ms,95%): 42.61 err/s: 0.00 reconn/s: 0.00[ 30s ] thds: 4 tps: 99.29 qps: 1587.17 (r/w/o: 1388.59/0.00/198.58) lat (ms,95%): 43.39 err/s: 0.00 reconn/s: 0.00

结论，满足预期目标，sysbench2 因为 RU 值大，所以同样任务，sysbench2 比 sysbench1 快。

测试资源抢夺

以 sysbench 做基准，先运行 chbench1 的 oltp_write_only 任务 10 分钟后，再陆续挂起 sysbench1 和 sysbench2 的 oltp_read_only 任务，最后以 chbench1 的身份再运行一个 oltp_read_only 任务

期望目标

• chbench1 的 oltp_read_only 任务中途插入，凭借 PRIORITY = HIGH 可以获得较多的资源

• chbench1 的 oltp_write_only 任务结束后，因为 BURSTABLE 资源释放，sysbench1 和 sysbench2 的 oltp_read_only 任务的计算速度提升，chbench1 的 oltp_read_only 任务也有所提升。

chbench1 的 oltp_write_only 开始任务运行后，系统约占 200RU。10 分钟后追加的 sysbench1 的 oltp_read_only 任务和 sysbench2 的 oltp_read_only 任务，chbench1 的 oltp_write_only 任务依然是 200RU, 而 sysbench1、sysbench2 的系统 RU 分别是 100 和 150。14:00 之前的时间线，chbench1、sysbench1、sysbench2 分别是 200RU、100RU、150RU.

最后插入 chbench1 的 oltp_read_only 任务，chbench1 升到 500 以上的 RU，平均值接近 550RU。而 sysbench1 和 sysbench2 并没有任何变化，依然是 100 和 150 左右徘徊。14:00 到 14:30 的时间线，chbench1、sysbench1、sysbench2 分别是 500、100RU、150RU.

chbench1 的 oltp_write_only 任务结束后，sysbench1 仍然占系统的 100RU，oltp_write_only 资源释放后， 而 sysbench2 迅速从原来的 150RU 升到接 500RU，而 chbench1 的 oltp_read_only 任务速度有了质量的提升，飙升到 2500RU。14:30 到 14:45 的时间线，chbench1、sysbench1、sysbench2 分别是 2500、100RU、500RU.

14:45 后，sysbench1 和 sysbench2 任务结束后，chbench1 的 RU 进一步急升。14:45 之后的时间线，chbench1 是 3000RU

结论，chbench1、sysbench1、sysbench2 三者竞争，优先满足 chbench1 的资源需求，sysbench2 与 chbench1 竞夺，自己只占有 150 的 RU。 chbench1 拥有优先权，可以继续给 chbench1 添加任务。在 chbench1 的部分资源释放后，可以提供给 sysbench2 使用。

测试资源耗尽

以 chbenchmark 做基准，通过 chbench1 和 sysbench 对集群发起 HTAP 的压力测试，机器预先加载有 tpc-h 数据，期望平台会对客户提交的不合理要求截断，并提示报警。

​/root/.tiup/components/bench/v1.12.0/tiup-bench ch --host 192.168.10.13 -Usysbench1 -p123456 -P4000 --warehouses 1 run -D chbenchmark -T 1000 -t 50 --time 60m​​​/root/.tiup/components/bench/v1.12.0/tiup-bench ch --host 192.168.10.13 -Uchbench1 -p123456 -P4000 --warehouses 2 run -D chbenchmark -T 10000 -t 50 --time 60m​

sysbench1 的执行过程中报错，提示 failed Error 8252: Exceeded resource group quota limitation，整体系统依然在运行，没有对租户采取强硬措施处理。

chbench1 的执行过程中没有报错，系统在持续满足它的资源需求，没有对租户采取强硬措施处理，直到系统不胜负荷，wait 使用 100%，swap 使用 100%。

结论，面对 chbench1 和 sysbench1 的不合理要求，系统没有把它强行掐断，结果恶性循环导致系统资源消耗殆尽。

通过负载校准

2379 监控界面的负载校准必须要持续一段的压力才能出结果，技术原理它是按时序采集压测数据，根据对系统访问，算出平台应该调成多大 RU 负载。

笔者设了密集的频发的压力测试，经过系统计算后结果是 8536RH，相对原来的硬件推荐的 14886RU 要少。选用 8536RH 比起 14886RU　更合理。

/root/.tiup/components/bench/v1.12.0/tiup-bench ch --host 192.168.10.13 -Uchbench1 -p123456 -P4000 --warehouses 2 run -D chbenchmark -T 10000 -t 50 --time 60m​​​​sysbench   /usr/share/sysbench/oltp_read_only.lua  --mysql-user=sysbench1 --mysql-password='123456' --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run​sysbench   /usr/share/sysbench/oltp_read_only.lua  --mysql-user=sysbench2 --mysql-password='123456' --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run

结论，负载校准相对硬件配置校准的极限负荷，表现更真实，更贴近资源的分配。

总结

多租户管理充分利用了资源，面对百万来宾，不需要摆百万宴席，也不需要假设性十万宴席，通过科学有效的现代化管理手段 ，万人宴席就好。

资源隔离是多租户必备的基本能力，每个租户分配的资源不一样，才能有序进行工作。

资源抢夺是多租户的核心处理能力，当出现竞争的时候，保障 VIP 食客先吃，低级别的用户也可以吃一部分。VIP 食客户快速吃完抂，再腾资源出来，整体协调共进。

资源耗尽是多租户最想避免发生的事情，目前资源管控都是通过 cgroup 技术实现的，本质也是线程管控的。估计这里的测试 chbechmark 的线程并发有关系，里面有执行 tpc-h 的昂贵执行，跨越管控，最后发生资源耗尽。

通过负载校准是未来的技术趋势，与数据库 AI 有关，根据真实的业务负荷提供调整数据库建议参数，目前 AI 在 TiDB 的应用是租户资源调整，以后还会有很多增长空间。

笔者只知道国产数据库中，只有 OceanBase 有多租户功能，TiDB 直至 7.1 才推出成熟的资源管控手段 ，来的迟，但是没有晚，亮点让人耳目一新，TiDB7.1 的硬件配置校准继承传统的资源管控策略，按照工程师的熟悉习惯对服务器配置规格分配资源，同时也在负载校准提供了新的手段，通过人工智能识别数据库的最佳参数。

相对 OB 的大而周全，TiDB 是小而精致。OB 新建用户，都必须绑定租户，绑定租户需要三步走，三步走之前必须算好我应该划分多少个 CPU、多少内存。 而 TiDB 假设你没有多租户的需求，那么你直接新建用户，不需要你强制绑定资源组。这样一对比，TiDB 的多租户显得锦上添花了！