TiDB v7.1.0资源管控调研与评测

多租户是什么

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

一个笨方法是先入先出【FIFO】，通过先入者得到座席，吃完后先出去的方式，但是很快就出现问题 。有些客人是吃货长服务，他们点了烤乳猪潮汕毒药砂锅粥烧鹅囱鹅肠粉干炒牛河 ，结果只分配了他们5个座席，他们只能默默的吃，占住位置不释放。另外资源分配也有类似的问题，最后发生所有的座席满员，其它的人只能等待。可怜短服务需求的人，有些人不远***过来只为吃一粒牛肉丸，有些人只为了吃一个叉烧包。因为愚蠢程序的设计，结果等着等着，活生生饿死，造成系统大面积瘫痪。

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

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

TiDB与***的多租户或多或少都借鉴capacity Schedulert和fair Schedulert的某些特性。

数据库的多租户

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

创建15个CPU，3G内存的资源单位unitfish obclient [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 primary_zone=RANDOM, locality=F@zone1 set variables ob_compatibility_mode=mysql, ob_tcp_invited_nodes=%; Query OK, 0 rows affected (24.164 sec)

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

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

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

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

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

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

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

区别于OB的细粒度管控方式，TiDB通过PRIORITY和BURSTABLE对资源争夺进行管控，如果发生资源恶性竞争，优先满足PRIORITY高的资源组，如果发生资源闲置，打上BURSTABLE的资源组允许当系统有过多的空闲资源，它可以占用更多的资源。

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

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

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

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

实验环境

故事背景两个小弟是sysbech1【对应RG1】，sysbech2【对应RG2】，一个大佬是chbench1【对应RG3】。

以下创建三个资源组，RG1是100，RG2是500，RG3是2000，如下。

其中RG3是贵宾拥有最高优先权，而RG1和RG2则是同样级别，不过RG2的资源要RG1多。

选 用sysbench以及chbenchmark做压力性能的测试。

测试资源隔离

以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= (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.6 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

假如我把rg1设成 BURSTABLE，在系统空闲的时间rg1会汲取其它的资源，rg2设置调成200

URCE_GROUPS; +---------+------------+----------+-----------+ | NAME    | RU_PER_SEC | PRIORITY | BURSTABLE | +---------+------------+----------+-----------+ | default | UNLIMITED  | MEDIUM   | YES       | | rg1     | 100        | MEDIUM   | YES       | | rg2     | 200        | MEDIUM   | NO        | +---------+------------+----------+-----------+ 3 rows in set (0.00 sec)

结论，sysbench1是100，sysbench2是500，sysbench2平均值是sysbench1的5倍,满足预期目标。sysbench1是100，sysbench2是200，因为BURSTABLE，sysbench虽然说是100但是可以占用系统其它空闲资源，指数一直上升，而sysbech因为是200，一直在200之间徘徊。

测试资源抢夺

以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任务结束后，因为资源释放，sysbench1和sysbench2的oltp_read_only任务的计算速度提升，chbench1的oltp_read_only任务也有所提升。

1.首先运行chbench1的oltp_write_only任务 sysbench   /usr/share/sysbench/oltp_write_only.lua --mysql-user=chbench1 --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 4.运行chbench1的oltp_read_only任务 sysbench   /usr/share/sysbench/oltp_read_only.lua --mysql-user=chbench1 --mysql-password=123456 --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=10 --time=3000 --report-interval=10   run

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【本身分配500RU】。 chbench1拥有优先权，本身的oltp_write_only任务只吃200RU的资源，继续给chbench1添加任务oltp_read_only，吃了将近500RU。此刻系统一共有4个长任务进行中，直到oltp_write_only结束，sysbench2终于拿该属于自己的500RU，chbench1也升到2500。 两个小弟吃完了，只剩下老大一人独吃，吃到了3000RU。

测试资源耗尽

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

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

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

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

通过负载校准

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

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

8536 RU代表集群总资源个数，随着压测会不断 变化，负载校准是一个变量。 有经验的工程师，可以借鉴它调整整个集群的资源分配。但是笔者觉得这里美中不足，负载校准应该以时间版本的方式反映它多个时间阶段 不同的负荷，这样更有利于工程师做出精准的选择。

/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 -tql-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

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

总结

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

资源隔离是多租户必备的基本能力，每个租户分配的资源不一样，才能有序进行工作。TiDB满足不同租户的资源隔离，通过打标签让租户可以使用系统的空闲资源。

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

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

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

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

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