0
1
2
0
专栏/.../

TiDB 7.5.1 资源管控测试

 像风一样的男子  发表于  2024-03-28

一、前言

诸位DBA是否经常遇到过如下问题:

1、当集群突然遇到某些 SQL 引发的性能问题时,为了不影响真个集群正常使用,只能忍痛停掉相关服务 。
2、当某个业务处于高峰期时,会过多占用整个数据库系统的资源,进而影响别的业务正常运行。

TiDB v7.1.0开始支持基于资源组的资源管控,为同一集群中的不同工作负载分配并隔离资源。该功能显著提升了多应用集群的稳定性。

TiDB 资源管控提供了两层资源管理能力,分别在TiDB 层和TiKV层的优先级调度。将用户绑定到某个资源组后,TiDB 层会根据用户所绑定资源组设定的配额对用户的读写请求做流控,TiKV 层会根据配额和优先级来对请求做调度。通过流控和调度这两层控制,可以实现用户、会话、语句级别的应用资源隔离。

资源管控已经推出半年较为成熟,之前社区小伙伴已经做了很详细的测评。

最近有这方面需求就做了个简单的功能测试。

二、升级版本

之前数据库所使用版本为5.4.3(一直稳定运行,没有升级的动力)。现在把该集群升级到最新的7.5.1.

image.png

image.png

在dashboard中可以看到新加入的资源管控页面。

image.png

三、创建资源组和用户

Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的计量单位,用于表示对数据库的单个请求消耗的资源量。请求消耗的 RU 数量取决于多种因素,例如操作类型或正在检索或修改的数据量。

集群资源的评估,一开始只能通过系统自动根据硬件配置来计算得到总RU量,然后根据这个估计得到的量,创建资源组、分配租户。

运行一段时间后,会根据这段时间的实际负载获得准确的总RU和消耗量,这个时候还需要管理员介入,再次调整之前不同租户的资源组所持有的分配额。

创建资源组

CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 10000;

CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 20000;

创建用户绑定到对应资源组

CREATE USER 'usr2'@'%' IDENTIFIED BY '123456' RESOURCE GROUP rg2;

 CREATE USER 'usr1'@'%' IDENTIFIED BY '123456' RESOURCE GROUP rg1;

然后就可以在dashboard重要到相关资源组的信息。

image.png

也可以在数据库中查询到用户和资源组的绑定关系。

[root@tsp-tidb-taos-01 ~]# mysql -h 127.0.0.1 -P4000 -uusr1 -p

Enter password:

MySQL [(none)]> select host, user,User_attributes from mysql.user;

+------+------+---------------------------+

| host | user | User_attributes           |

+------+------+---------------------------+

| %    | root | NULL                      |

| %    | read | NULL                      |

| %    | usr1 | {"resource_group": "rg1"} |

| %    | usr2 | {"resource_group": "rg2"} |

+------+------+---------------------------+

4 rows in set (0.00 sec)

MySQL [(none)]>

四、关闭资源管控做压力测试

先关闭资源管控

SET GLOBAL tidb_enable_resource_control = 'OFF';

image.png

建库 sbtest 

MySQL [(none)]> create database sbtest;

sysbench主要对集群做基准测试,主要关注TPS、QPS

远程连接进入shell环境, 安装sysbench

[root@tsp-tidb-taos-01 ~]# yum install sysbench

[root@tsp-tidb-taos-01 ~]# sysbench --version

sysbench 1.0.17

初始化压测数据建100张表

sysbench oltp_common --threads=32 --rand-type=uniform  --db-driver=mysql --mysql-db=sbtest --mysql-host=10.20.10.137 --mysql-port=4000 --mysql-user=usr1 --mysql-password='123456'  --tables=100 --table-size=10 prepare

启动一个sysbench 任务做写入测试 

[root@taos3 sysbench]# sysbench oltp_write_only    --threads=512     --rand-type=uniform  --db-driver=mysql     --mysql-db=sbtest     --mysql-host=10.20.10.137  --mysql-port=4000     --mysql-user=usr1     --mysql-password='123456'      --tables=16 --table-size=10000000 --report-interval=10 --time=300 run

image.png

image.png

image.png

可以看到服务器资源利用率非常高,资源管控相关监控应为关闭功能看不到数据了。

开启资源管控测试

SET GLOBAL tidb_enable_resource_control = 'ON';

同样的测试方法只启动一个压测任务

[root@taos3 sysbench]# sysbench oltp_write_only    --threads=512     --rand-type=uniform  --db-driver=mysql     --mysql-db=sbtest     --mysql-host=10.20.10.137  --mysql-port=4000     --mysql-user=usr1     --mysql-password='123456'      --tables=16 --table-size=10000000 --report-interval=10 --time=300 run

image.png

image.png

从测试结果和监控指标中可以看到资源控制的非常精确。

换个用户usr2做测试

[root@taos3 sysbench]# sysbench oltp_write_only    --threads=512     --rand-type=uniform  --db-driver=mysql     --mysql-db=sbtest     --mysql-host=10.20.10.137  --mysql-port=4000     --mysql-user=usr2     --mysql-password='123456'      --tables=16 --table-size=10000000 --report-interval=10 --time=300 run

image.png

image.png

usr2的压测结果和资源使用量都是usr1的2倍

 

加大资源组的限额

ALTER RESOURCE GROUP rg1  RU_PER_SEC = 50000;

ALTER RESOURCE GROUP rg2 RU_PER_SEC = 100000;

 

同时开启usr1、usr2用户启动2个sysbench任务做压测

sysbench oltp_write_only    --threads=512     --rand-type=uniform  --db-driver=mysql     --mysql-db=sbtest     --mysql-host=10.20.10.137  --mysql-port=4000     --mysql-user=usr1     --mysql-password='123456'      --tables=16 --table-size=1000000000 --report-interval=10 --time=300 run

image.png

任务2

 sysbench oltp_write_only    --threads=512     --rand-type=uniform  --db-driver=mysql     --mysql-db=sbtest     --mysql-host=10.20.10.137  --mysql-port=4000     --mysql-user=usr2     --mysql-password='123456'      --tables=16 --table-size=1000000000 --report-interval=10 --time=300 run

image.png

image.png

压测结果和监控指标符合预期。

修改资源组总限额超过系统给的估算值(写入为219552RU/s)。

ALTER RESOURCE GROUP rg1  RU_PER_SEC = 100000;

ALTER RESOURCE GROUP rg2 RU_PER_SEC = 200000;

image.png

同时启动2个任务进行测试

sysbench oltp_write_only    --threads=512     --rand-type=uniform  --db-driver=mysql     --mysql-db=sbtest     --mysql-host=10.20.10.137  --mysql-port=4000     --mysql-user=usr1     --mysql-password='123456'      --tables=16 --table-size=100000000 --report-interval=10 --time=300 run

sysbench oltp_write_only    --threads=512     --rand-type=uniform  --db-driver=mysql     --mysql-db=sbtest     --mysql-host=10.20.10.137  --mysql-port=4000     --mysql-user=usr2     --mysql-password='123456'      --tables=16 --table-size=100000000 --report-interval=10 --time=300 run

image.png

image.png

image.png

2个任务发生了资源抢夺。

如果设置了优先级,TiDB 会优先满足高优先级 (PRIORITY) 资源组的请求。如果同一优先级的请求无法全部满足,TiDB 会根据用量 (RU_PER_SEC) 的大小按比例分配。这里就不一一测试了。

总结

TIDB的resource control资源管控,将cpu/内存/io的物理资源抽象成RU的感念,简化了使用方式,并且测试中发现该特性可以正常限制住RU,达到资源控制的效果。

可以将 TiDB 当做一个资源池,资源不够时可以添加 TiDB 或 TiKV 资源来扩大资源池。

TiDB的硬件配置校准如果能通过人工智能识别自动调整就完美了。

0
1
2
0

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论