写点什么

TiDB 7.1 资源管控验证测试

  • 2023-07-07
    北京
  • 本文字数:4226 字

    阅读完需:约 14 分钟

作者: dba-kit 原文来源:https://tidb.net/blog/9cd7dcb3

〇、背景

我们线上使用环境和李文杰大佬比较类似,我这里就不赘述了,大家可以看专栏 - TiDB v7.1.0 跨业务系统多租户解决方案 | TiDB 社区,这里比较清晰的介绍了 7.1 的资源管控原理和实践验证。


本文章的重点在通过实验探索资源管控的一些细节表现,详细来讲就是:TiDB 的流控能力和 TiKV 的调度能力。


  • TiDB 流控能力:是看在 tidb-server 资源不足的情况,是否能正确按照 Quota 限制特定用户的使用资源。

  • TiKV 调度能力:是看在 TiKV 资源不足时候,能否优先响应高优先级的资源组请求,以及和当前 tidb-server 的优先级的区别。

一、测试环境准备

创建用户及资源组

CREATE RESOURCE GROUP IF NOT EXISTS rg_5000 RU_PER_SEC=5000;CREATE RESOURCE GROUP IF NOT EXISTS rg_5000_high RU_PER_SEC=5000 PRIORITY = HIGH;
CREATE RESOURCE GROUP IF NOT EXISTS rg_3000 RU_PER_SEC = 3000;CREATE RESOURCE GROUP IF NOT EXISTS rg_3000_burstable RU_PER_SEC = 3000 BURSTABLE;
CREATE RESOURCE GROUP IF NOT EXISTS rg_30000_high RU_PER_SEC=30000 PRIORITY = HIGH;CREATE RESOURCE GROUP IF NOT EXISTS rg_30000_low RU_PER_SEC=30000 PRIORITY = LOW;
CREATE USER 'usr_rg_5000'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg_5000;GRANT ALL ON *.* TO 'usr_rg_5000'@'%';
CREATE USER 'usr_rg_5000_high'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg_5000_high;GRANT ALL ON *.* TO 'usr_rg_5000_high'@'%';
CREATE USER 'usr_rg_3000'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg_3000;GRANT ALL ON *.* TO 'usr_rg_3000'@'%';
CREATE USER 'usr_rg_3000_burstable'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg_3000_burstable;GRANT ALL ON *.* TO 'usr_rg_3000_burstable'@'%';
CREATE USER 'usr_rg_30k_high'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg_30000_high;GRANT ALL ON *.* TO 'usr_rg_30k_high'@'%';
CREATE USER 'usr_rg_30k_low'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg_30000_low;GRANT ALL ON *.* TO 'usr_rg_30k_low'@'%';
复制代码

准备测试数据

tiup-bench tpcc prepare --warehouses 100 -D tpcc_test --dropdata -H 172.18.x.x -U usr_rg_3000 -p 123 -P 4000 -T 50tiup-bench tpcc prepare --warehouses 100 -D tpcc_test2 --dropdata -H 172.18.x.x -U usr_rg_3000 -p 123 -P 4000 -T 50
复制代码

二、测评方案

2.1 TiDB 流控测评

测试方案

测试目标:


  • 不同资源组连到同一个 TiDB 上,测试不同资源组之间的隔离性

  • 同一个用户连到不同 TiDB 上,测试同一用户的 Quota 是否共用

  • 同一资源组不同用户,测试同一资源组的 Quota 是否共用

2.1.1 不同资源组的隔离性

#! /bin/bash
# 1. 使用usr_rg_3000_burstable用户作为测试的背景噪音,令TiDB的CPU尽可能高echo "$(date +"%F %T"): start bench use usr_rg_3000_burstable for 2h"nohup tiup-bench tpcc run -D tpcc_test2 --host 172.18.x.x -U usr_rg_3000_burstable -p 123 -P 4000 -T 50 --time 2h >usr_rg_3000_burstable.log &
# 2. 5-35min. 3000 for 30m (后续每隔5min启动一个测试用户进行压测)sleep 300echo "$(date +"%F %T"): start bench use usr_rg_3000 for 30m"nohup tiup-bench tpcc run -D tpcc_test2 --host 172.18.x.x -U usr_rg_3000 -p 123 -P 4000 -T 50 --time 30m >usr_rg_3000.log &
# 3. 10-45min. 5000 for 30msleep 300echo "$(date +"%F %T"): start bench use usr_rg_5000 for 30m"nohup tiup-bench tpcc run -D tpcc_test2 --host 172.18.x.x -U usr_rg_5000 -p 123 -P 4000 -T 50 --time 30m >usr_rg_5000.log &
# 4. 15-20min. 5000 for 5msleep 300echo "$(date +"%F %T"): start bench use usr_rg_5000 for 5m"nohup tiup-bench tpcc run -D tpcc_test2 --host 172.18.x.x -U usr_rg_5000 -p 123 -P 4000 -T 50 --time 5m >usr_rg_5000-2.log &
#5. 25-55min. 3000 high for 30msleep 300echo "$(date +"%F %T"): start bench use usr_rg_3000_high for 30m"nohup tiup-bench tpcc run -D tpcc_test2 --host 172.18.x.x -U usr_rg_3000_high -p 123 -P 4000 -T 50 --time 30m >usr_rg_3000_high.log &
# 6. 30-35min. 5000 for 5msleep 300echo "$(date +"%F %T"): start bench use usr_rg_5000 for 5m"nohup tiup-bench tpcc run -D tpcc_test2 --host 172.18.x.x -U usr_rg_5000 -p 123 -P 4000 -T 50 --time 5m >usr_rg_5000-2.log &
复制代码

测试结果

时序图



测试结果



结果解析


  1. 阶段 1:由于只有usr_rg_3000_burstable一个用户在使用集群,虽然 Quota 设置为 3k,但因为设置了BURSTABLE可以跑到 22k

  2. 阶段 2-4:并发一直在增大,TiDB 的负载在逐渐增加,usr_rg_3000_burstable的流控曲线 (黄色曲线) 也越来越低,从 22k、7.5k、6k 逐步降低至 4k

  3. 阶段 4:虽然使用usr_rg_5000用户新增了一个 TPCC 压测进程,但是总的资源消耗不变,还是 5k。

  4. 阶段 5:随着usr_rg_5000一个压测进程结束,usr_rg_3000_burstable的资源从 4k 增加到 5k(不过usr_rg_5000总的资源消耗略有下降,从 5k 下降至 4.8k,可能是 TiDB 压力太大导致的)

  5. 阶段 6:继续使用 usr_rg_5000 用户新增了一个 TPCC 压测进程, 这一场景其实和阶段 4 比较类似,不过新增了usr_rg_3000_high资源组的压测进程,此时 TiDB-Server 的压力是最大的,几个资源组的曲线都略有波动,不过波动不大

  6. 阶段 7-10:随着其他资源组的压测进程逐渐结束,TiDB 的负载在逐渐降低,usr_rg_3000_burstable的流控曲线 (黄色曲线) 也越来越高,逐步回升到 24k。


由此来看,TiDB-Server 层的流控还是比较符合预期的,当负载压力小的时候,允许部分用户超额使用资源,当负载压力大的时候,又能保证其他用户的 Quota 正常。

2.1.2 同一用户不同 tidb-server

测试命令


nohup tiup-bench tpcc run -D tpcc_test --host 172.18.9.4 -U usr_rg_3000 -p 123 -P 4000 -T 50 --time 5m  >usr_rg_3000.log.1 &sleep 60;nohup tiup-bench tpcc run -D tpcc_test --host 172.18.9.4 -U usr_rg_3000 -p 123 -P 14000 -T 50 --time 5m  >usr_rg_3000.log.2  &
复制代码


测试结果




结果解析


  • 观察 RU 使用曲线:在第二个压测进程启动后,资源使用会短时间高于 Quota;当第一个压测进程结束后,资源使用会短时间低于 Quota;不过很快就会回归正常 Quota。

  • 观察 tidb-sever 的 CPU 曲线:当只有一个压测进程在跑时候,单个 tidb-server 的 CPU 是正常使用的,当两个压测进程共同跑时候,两个 tidb-server 会平均分配负载,达到负载均衡的状态,更合理使用资源。

2.1.3 不同用户同一资源组

压测命令


CREATE USER 'usr_rg_3000_2'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg_3000;grant all on *.* to 'usr_rg_3000_2'@'%';
复制代码


nohup tiup-bench tpcc run -D tpcc_test --host 172.18.9.4 -U usr_rg_3000 -p 123 -P 4000 -T 50 --time 5m  >usr_rg_3000.log.1 &sleep 60;nohup tiup-bench tpcc run -D tpcc_test --host 172.18.9.4 -U usr_rg_3000_2 -p 123 -P 14000 -T 50 --time 5m  >usr_rg_3000.log.2  &
复制代码


压测结果




结果解析


通过监控曲线,可以看到同一资源组的两个不同用户,和同一用户两个不同压测进程的曲线是基本一致的,说明同一资源组内的不同用户是共享 Quota 的。

2.1.4 总结

因为同一资源组内不同用户是共享 Quota 的,所以个人理解的 TiDB 的流控最佳实践为:


  • 对所有资源组都设置BURSTABLE属性,这样才能提高 TiDB-Server 的资源利用率。

  • 针对 OLAP 场景的用户,可以设置一个较小的 Quota,当资源紧张时候,让它们尽可能小的占用资源,不影响 OLTP 的查询。

2.2 TiKV 调度能力测试

由于 2.1 的测试案例,只有一个 TiDB-Server 实例,最终的 TiKV 压力并不大,看不出来 TiKV 层的优先级调度能力。使用tiup cluster edit-config将 tikv-server 配置修改为resource_control.cpu_quota: 400%,降低 TiKV 的 CPU 资源。


通过instance.tidb_force_priority来对特定 TiDB-Server 上的查询来设置优先级,测试一下通过 TiDB-Server 隔离,和通过资源组来设置的优先级有什么区别。


mysql> show config where name like '%tidb_force_priority%';+------+------------------+------------------------------+---------------+| Type | Instance         | Name                         | Value         |+------+------------------+------------------------------+---------------+| tidb | 172.18.9.4:4000  | instance.tidb_force_priority | HIGH_PRIORITY || tidb | 172.18.9.4:14000 | instance.tidb_force_priority | LOW_PRIORITY  |+------+------------------+------------------------------+---------------+2 rows in set (0.01 sec)
复制代码


测试案例包括:


  • 资源组 PRIORITY 不同,TiDB 的 PRIORITY 相同

  • 资源组 PRIORITY 相同,TiDB 的 PRIORITY 不同

  • 高 PRIORIT 的资源组连接低 PRIORITY 的 TiDB vs. 低 PRIORIT 的资源组连接高 PRIORITY 的 TiDB

2.2.1 资源组 PRIORITY 不同,TiDB 的 PRIORITY 相同

为使 TiKV 的 CPU 达到瓶颈,使用大 Quota 的资源组来进行测试


nohup tiup-bench tpcc run -D tpcc_test --host 172.18.9.4 -U usr_rg_30k_low -p 123 -P 4000 -T 100 --time 5m &sleep 120;nohup tiup-bench tpcc run -D tpcc_test --host 172.18.9.4 -U usr_rg_30k_high -p 123 -P 4000 -T 100 --time 5m  &
复制代码


2.2.2 资源组 PRIORITY 相同,TiDB 的 PRIORITY 不同

nohup tiup-bench tpcc run -D tpcc_test --host 172.18.9.4 -U usr_rg_30k_low -p 123 -P 4000 -T 100 --time 5m &sleep 120;nohup tiup-bench tpcc run -D tpcc_test --host 172.18.9.4 -U usr_rg_30k_low -p 123 -P 14000 -T 100 --time 5m  &
复制代码




2.2.3 高 PRIORIT 的资源组连接低 PRIORITY 的 TiDB vs. 低 PRIORIT 的资源组连接高 PRIORITY 的 TiDB

nohup tiup-bench tpcc run -D tpcc_test --host 172.18.9.4 -U usr_rg_30k_low -p 123 -P 4000 -T 100 --time 5m &sleep 120;nohup tiup-bench tpcc run -D tpcc_test --host 172.18.9.4 -U usr_rg_30k_high -p 123 -P 14000 -T 100 --time 5m  &
复制代码




2.2.4 总结

综合三次测试,可以发现不管是资源组优先级还是 tidb-server 的优先级,在 TiKV 层都是同样的处理,其调度能力并不能按照预期体现。


发布于: 刚刚阅读数: 5
用户头像

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
TiDB 7.1 资源管控验证测试_版本测评_TiDB 社区干货传送门_InfoQ写作社区