关于tidb:TiDB-710-LTS-特性解读丨关于资源管控-Resource-Control-应该知道的-6-件事

TiDB 7.1.0 LTS 在前段时间公布，置信很多同学都曾经领先应用了起来，甚至都未然通过一系列验证推向了生产环境。面对 TiDB 7.1 若干重要个性，新 GA 的资源管控 (Resource Control) 是必须要充沛了解、测试的一个重量级个性。对于长年奋斗在一线 DBA 岗位的我来说，学术方面的精进曾经力不从心，大部分的工夫都在强化“术”的方面，所以 TiDB 每更（新）必追，每个新 GA 的个性都要相熟，这样当生产环境 TiDB 降级到指标版本后，才不至于慌手慌脚，新建 TiDB 集群后能力对新个性轻车熟路。置信本文会给读者敌人们带来一些实质性的播种。言归正传，本文将围绕“资源管控”主题，具体说说对于 “资源管控” 您应该晓得的 6 件事。

从用户场景登程，看个性如何应用

从 200+ 的国产数据库中怀才不遇，其无效、齐备的文档当属“功不可没”。在 TiDB 7.1 的文档中是这样形容应用场景的：

资源管控个性的引入对 TiDB 具备里程碑的意义。它可能将一个分布式数据库集群划分成多个逻辑单元，即便个别单元对资源适度应用，也不会挤占其余单元所需的资源。利用该个性：

○ 你能够将多个来自不同零碎的中小型利用合入一个 TiDB 集群中，个别利用的负载升高，不会影响其余业务的失常运行。而在零碎负载较低的时候，忙碌的利用即便超过设定的读写配额，也依然能够被调配到所需的系统资源，达到资源的最大化利用。

○ 你能够抉择将所有测试环境合入一个集群，或者将耗费较大的批量工作编入一个独自的资源组，在保障重要利用取得必要资源的同时，晋升硬件利用率，升高运行老本。

○ 当零碎中存在多种业务负载时，能够将不同的负载别离放入各自的资源组。利用资源管控技术，确保交易类业务的响应工夫不受数据分析或批量业务的影响。

○ 当集群遇到突发的 SQL 性能问题，能够联合 SQL Binding 和资源组，长期限度某个 SQL 的资源耗费。

那么，从求实的 DBA 角度来看这段话，可能会是上面这个样子：

资源管控，这一新个性，将数据库中的用户、会话、SQL 等日常行为的性能指标做了更加粗疏的量化解决。引入了 “Request Unit (RU)” 这一量化概念，目前包含了 CPU, IOPS, IO 带宽三个重要指标，将来还会减少内存、网络等指标。

○ 能够将若干 MySQL 数据库合并进一个 TiDB 集群，比方读写峰值常呈现于日间的 OA 零碎，读写峰值常呈现于夜间的 Batch 零碎，以及 24 小时运行但负载继续稳固的数据采集零碎，这种“三合一”的形式，使得各零碎“错峰出行”，借助资源管控的能力“按需分配”，以此达到升高综合老本的指标。

○ 在一个 TiDB 集群，为不同测试环境 (Env) 创立不同测试用户 (User)，而后根据测试所需资源规格创立不同资源组 (Resource Group)，并将用户与对应的资源组做绑定。如此做到了不同用户的资源隔离，因为是测试环境，可将资源组设置为超限 ( BURSTABLE ) ，或者了解为“超卖”，某个或某几个用户应用的资源超过了资源组规定的限度，仍旧能够失常应用，而不影响测试，能够最大化利用硬件资源。不过，这里的测试应该了解为业务测试，而非标准的性能测试，不然须要更加谨严的思考资源分配以及超限 ( BURSTABLE ) 的应用。

○ 相似于第一节中的形容，三个零碎别离对应三个资源组，且 BURSTABLE 的设定为 NO，那么三个零碎应用的资源将是隔离的，不受彼此影响。也就是说，在以后 TiDB 集群中，即便 TP、AP 业务同时运行，因为应用了资源管制个性，此时 TP 业务并不会受到 AP 业务的烦扰。

○ 业务是一直变动的，“Bad SQL” 问题随时可能产生，如果某条 SQL 占用资源 (RU) 过高，影响该用户的其余 SQL 性能。此时，能够新建一个资源组，并能够应用执行打算绑定(SQL Binding)性能，将该 SQL 语句绑定到新建的资源组上，以起到限度 SQL 资源耗费，甚至回绝 SQL 执行的目标。测试 SQL 如下：

CREATE RESOURCE GROUP rg1 RU_per_SEC=1;CREATE GLOBAL BINDING FOR  SELECT COUNT(*) FROM t1 t JOIN t1 t2 USING (uid) USING  SELECT /*+ resource_group(rg1) */ COUNT(*) FROM t1 t JOIN t1 t2 USING (uid);EXPLAIN ANALYZE FORMAT = 'verbose' SELECT COUNT(*) FROM t t1 JOIN t1 t2 USING (uid);

为了实现上述场景，TiDB 实现了若干 SQL 语法，接下来看看如何具体操作。

“资源管制”相干SQL，用这些就够了

钻研 TiDB 的人还有不晓得 AskTUG [1] 的么？半年前，@社区小助手整顿了一篇极具实用价值的帖子 -- 【社区智慧合集】TiDB 相干 SQL 脚本大全 [2] ，内含 38 条实用 SQL，是 TiDBer 们必珍藏的帖子之一。

彼时“资源管制”性能尚未“问世”，所以帖子里并不蕴含该个性相干 SQL，上面我将“资源管制”相干的精髓 SQL 贴出，以供参考。

1) 增删改查 -- 资源组 (Resource Group)

增：

-- 创立 `rg1` 资源组，限额是每秒 `500 RU`，优先级为 `HIGH`，容许这个资源组的超额 (`BURSTABLE`) 占用资源。CREATE RESOURCE GROUP IF NOT EXISTS rg1   RU_PER_SEC = 100  PRIORITY = HIGH  BURSTABLE;-- 创立 `rg2` 资源组，限额是每秒 `500 RU`，其余选项为默认值。CREATE RESOURCE GROUP rg2 RU_PER_SEC = 200;

删：

-- 删除资源组DROP RESOURCE GROUP rg2;

改：

-- 批改资源组资源配置ALTER RESOURCE GROUP rg2 ru_per_sec = 2000;

查：

-- 通过 I_S 表查看SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS;

须要留神的是，创立、批改、删除资源组，须要领有 SUPER 或者 RESOURCE_GROUP_ADMIN 权限，否则会遇到报错：

ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or RESOURCE_GROUP_ADMIN privilege(s) for this operation

2) 绑定用户到 Resource Group

将某个用户绑定到资源组

将用户和资源组绑定很简略，其实就是批改用户的属性。如果是已创立的用户，能够用 ALTER USER ，如果是新建用户，则可用 CREATE USER 。

-- CREATECREATE USER u3 RESOURCE GROUP rg3;-- ALTERALTER USER u2 RESOURCE GROUP rg2;

查看某个用户绑定到资源组

这里有两种办法和二个问题，两种办法是别离通过 mysql 库和 INFORMATION_SCHEMA 库进行查问。

mysql> SELECT User, JSON_EXTRACT(User_attributes, "$.resource_group") AS RG FROM mysql.user ;+------+-----------+| User | RG        |+------+-----------+| root | NULL      || u1   | "default" || u2   | "rg2"     || u3   | ""        |+------+-----------+4 rows in set (0.00 sec)

问题一：Resource Group 的 \** 和 default 等同**

从下面的查问后果来看，除了普通用户 u2 绑定的资源组 rg2 之外，其余三个用户其实都应用的是默认资源组，即 default 。只是这里呈现了空 (``)，可能会造成稍许疑虑，经与官网同学确认， “空和 default 在行为下面是一样的” 。交换帖子参见： resource control，default resource group 文档勘误 [3]

问题二：通过 INFORMATION_SCHEMA.USER_ATTRIBUTES 暂无奈查问用户绑定的资源组

普通用户是无权通过 mysql 库查问哪些用户绑定了哪些资源组的，包含以后用户，然而每个用户都能够通过 I_S 库查问本人应该能够获取的信息。所以办法二，是指普通用户通过查问 I_S 库来获取相干信息，SQL 如下：

SELECT * FROM INFORMATION_SCHEMA.USER_ATTRIBUTES;

只是目前成果不如意，期待下个版本会失去改良。相干帖子参见： resource control 相干，INFORMATION_SCHEMA.USER_ATTRIBUTES 表取值问题 [4]

3) 绑定会话到 Resource Group

后面提到了绑定用户到 RG，其实 TiDB 提供了更加灵便的形式，能够绑定会话 (Session) 到 RG，以及绑定 SQL 语句到 RG。

将以后会话绑定到资源组

SET RESOURCE GROUP rg1;

查看以后会话所应用的资源组

SELECT CURRENT_RESOURCE_GROUP();

重置以后会话绑定资源组

SET RESOURCE GROUP `default`;SET RESOURCE GROUP ``;

注：两条 SQL 的性能等价，但倡议应用第一条，起因参见【问题一】。

4) 绑定语句到 Resource Group

能够应用 Hint 来管制具体某条 SQL 语句占用的 RU 资源，举例如下：

SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t1 limit 10;

如何查看某条语句耗费的 RU 呢？能够通过理论执行打算来获取，举例如下：

EXPLAIN ANALYZE SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t1 limit 10;

5) 不可或缺的 PROCESSLIST

INFORMATION_SCHEMA 是 ANSI 规范中定义的一组只读视图，提供数据库中所有表、视图、列和过程的信息。多个关系型数据库中都有各自的实现，在 TiDB 的 INFORMATION_SCHEMA.PROCESSLIST 表中，减少了字段 RESOURCE_GROUP varchar(32) ，以此来显示以后沉闷会话应用的是哪个资源组。

案例如下，别离开三个窗口，启动三个会话，别离应用默认资源组，会话级资源组，和语句级资源组：

mysql -h 192.168.195.128 -P 4000 -c -u u1 -e 'select sleep(1000)'mysql -h 192.168.195.128 -P 4000 -c -u u2 -e 'SET RESOURCE GROUP `rg1`; select sleep(1000)'mysql -h 192.168.195.128 -P 4000 -c -u u3 -e 'SELECT /*+ RESOURCE_GROUP(rg1) */ * sleep(1000)'

此时用 root 用户查看 INFORMATION_SCHEMA.PROCESSLIST 表：

mysql> SELECT USER, RESOURCE_GROUP, INFO from INFORMATION_SCHEMA.PROCESSLIST ORDER BY USER;+------+----------------+-------------------------------------------------------------------------------------+| USER | RESOURCE_GROUP | INFO                                                                                |+------+----------------+-------------------------------------------------------------------------------------+| root | default        | SELECT USER, RESOURCE_GROUP, INFO from INFORMATION_SCHEMA.PROCESSLIST ORDER BY USER || u1   | default        | select sleep(1000)                                                                  || u2   | rg1            | select sleep(1000)                                                                  || u3   | rg1            | SELECT /*+ RESOURCE_GROUP(rg1) */ sleep(1000)                                       |+------+----------------+-------------------------------------------------------------------------------------+4 rows in set (0.00 sec)

相干探讨见此（感激 @db_user 的提醒）： resource control, 如何查看 session 级别变量 [5]

问题三：I_S.USER_ATTRIBUTES / I_S.RESOURCE_GROUPS 权限管制

接上例，如果应用普通用户，如 u2 用户查看 INFORMATION_SCHEMA.PROCESSLIST 表，则只会显示以后用户，或者说是权限范畴内能看到的信息：

mysql> SELECT USER, RESOURCE_GROUP, INFO from INFORMATION_SCHEMA.PROCESSLIST ORDER BY USER;+------+----------------+-------------------------------------------------------------------------------------+| USER | RESOURCE_GROUP | INFO                                                                                |+------+----------------+-------------------------------------------------------------------------------------+| u2   | rg2            | SELECT USER, RESOURCE_GROUP, INFO from INFORMATION_SCHEMA.PROCESSLIST ORDER BY USER || u2   | rg1            | select sleep(1000)                                                                  |+------+----------------+-------------------------------------------------------------------------------------+2 rows in set (0.00 sec)

这里的推断是， PROCESSLIST 作为既存表，权限设定都是延用之前的逻辑，这里只是减少了字段，所以很好的继承了权限隔离，即普通用户无权、无奈看到其余用户，如用户 u1 正在应用的资源组。

然而，对于新增的表 INFORMATION_SCHEMA.USER_ATTRIBUTES 和 INFORMATION_SCHEMA.RESOURCE_GROUPS 并没有做到如此细粒度的权限管制。

○ 对于表 USER_ATTRIBUTES ，普通用户能够查看所有用户的属性，如果【问题二】的性能实现，那么普通用户就能够查看到所有用户绑定的资源组。

○ 对于表 RESOURCE_GROUPS ，普通用户能够查看所有资源组。那么，对于 Bad SQL 问题，其实就有另外一种解决形式，开发者能够在 SQL 里写入 Hint，使得 Bad SQL 能够“越权”调用 default 资源组，轻则突破均衡，影响其余业务性能，重则打穿资源布局，再现 “一条 SQL 炮轰整个 TiDB 集群” 的威力。

从权限角度来看，资源管控所管制的不同资源组尽管做到了资源隔离，然而普通用户能够在 Session 级别随便切换资源组，比如说管理员将普通用户 u2 绑定资源组 rg1，然而 u2 登陆 TiDB 后，能够再切换到 rg2，以获取被调配更多资源的资源组的使用权。

相干交换贴链接： resource control, I_S 权限管制问题 [6]

正如我在帖子里提到的，对于 TiDB，高效、保质地实现性能是第一位的，权限 (Privileges) 实现次之，这是能够承受、了解的。毕竟，在如此内卷，国产数据库竞争如此强烈的市场环境下，“活下去”才是第一要务。但 Rule is Rule，权限（能够引申为“平安”）也是一个很重要、且绕不开的课题。

6) Resource Control 相干配置项

参见 官网文档 [7] ，资源管控引入的两个新变量，

TiDB：通过配置全局变量 tidb_enable_resource_control 管制是否关上资源组流控。

TiKV：通过配置参数 resource-control.enabled 管制是否应用基于资源组配额的申请调度。

查看办法如下：

-- tidbSHOW VARIABLES LIKE "tidb_enable_resource_control";-- tikvSHOW CONFIG WHERE NAME LIKE "resource-control.enabled";

7) Calibrate 资源估算

据文档 预估集群容量 [8] 介绍，目前有依据理论负载估算容量，基于硬件部署估算容量，两种估算形式，而比拟直观的办法是基于硬件部署估算容量形式，具体命名如下：

-- 默认 TPC-C 模型预测，等同于下一条命令CALIBRATE RESOURCE;-- 依据相似 TPC-C 的负载模型预测CALIBRATE RESOURCE WORKLOAD TPCC;-- 依据相似 sysbench oltp_write_only 的负载模型预测CALIBRATE RESOURCE WORKLOAD OLTP_WRITE_ONLY;-- 依据相似 sysbench oltp_read_write 的负载模型预测CALIBRATE RESOURCE WORKLOAD OLTP_READ_WRITE;-- 依据相似 sysbench oltp_read_only 的负载模型预测CALIBRATE RESOURCE WORKLOAD OLTP_READ_ONLY;

在 TiDB Dashboard v7.1.0 面板上，咱们能够看到新增了【资源管控】菜单，如图，

这里也能够查看资源预估状况，但实际上，Dashboard 也是调用下面的 SQL 进行预测，能够从 TiDB-Server 的日志中进行确认。

...[INFO] [session.go:3878] ... [sql="calibrate resource workload tpcc"]...[INFO] [session.go:3878] ... [sql="calibrate resource workload oltp_read_write"]...[INFO] [session.go:3878] ... [sql="calibrate resource workload oltp_read_write"]...[INFO] [session.go:3878] ... [sql="calibrate resource workload oltp_read_only"]...[INFO] [session.go:3878] ... [sql="calibrate resource workload oltp_write_only"]

此外，这款估算模型是基于 TiDB 的多年教训积攒，在基准测试的根底上实现的算法，实用于多种环境。引申一步，对于目前没有降级到 TiDB v7.1.0 版本的集群，或者须要对将要同步到 TiDB 集群的数据库进行容量估算，如何来解决呢？计算过程稍微简单，如果有趣味能够参考相干源码 calibrate_resource [9] 。

“资源管控”也须要监控

1) TiDB Dashboard

上文提到，TiDB Dashboard 减少了 【资源管控】 [10] 菜单，在页面下半局部，展现了 RU 相干图表，能够一目理解查看 TiDB 集群的 RU 负载状况，也能够选中图表的某个时间段，来应用 “依据理论负载估算容量” [11] 性能。

2) Grafana

绝对于 TiDB Dashboad，Grafana 提供了更全面的监控数据，甚至在面板上别离展现了读 RU (RRU) 和写 RU (WRU)。对于 RRU/WRU 的概念性形容较少，只是在 设计文档 [12] 的令牌桶 (Token Buckets) 章节和 Grafana 的参数介绍页面有所体现。

问题四：RRU/WRU 的表述问题

对于 RRU/WRU 的表述问题，其实只有关注 RU 就好，这是通过基准测试后的预测值，具备对立的观测价值，只是在监控面板上加以辨别，以观测 TiDB 集群的读写状况，在代码提交的记录里，也有研发同学的批注，“面向用户是 RU，监控项外面辨别是有更多细节”。相干交换贴参见：

resource control, Grafana 面板默认配置 [13]
resource control, Grafana 文档内容不残缺 [14]

3) RU 余量问题

对于日常运维，至多有两个监控指标须要思考：

○ 日常 RU 余量监控

○ 异样 RU 突增监控

其中，对于 RU 余量监控，TiDB 7.1 只能从 Grafana 面板上看到 RU 使用量，没有直观展现 RU 余量状况，所以在 TiDB 7.2 中失去了加强，具体实现可参考PR： resource_manager: add metrics for avaiable RU #6523 [15] 。

图 -- TiDB 7.1 的 Grafana 面板

图 -- TiDB 7.2 的 Grafana 面板

4) Log

从日志中能够看出什么时候真的开始调用了资源管控，然而无奈通过日志或者面板看出有哪些用户应用过资源组。

[2023/06/29 11:27:50.069 +09:00] [INFO] [session.go:3878] [GENERAL_LOG] [conn=7398943596793037429] [user=u2@192.168.195.128] [schemaVersion=53] [txnStartTS=0] [forUpdateTS=0] [isReadConsistency=false] [currentDB=] [isPessimistic=false] [sessionTxnMode=PESSIMISTIC] [sql="select @@version_comment limit 1"][2023/06/29 11:27:58.973 +09:00] [INFO] [session.go:3878] [GENERAL_LOG] [conn=7398943596793037429] [user=u2@192.168.195.128] [schemaVersion=53] [txnStartTS=0] [forUpdateTS=0] [isReadConsistency=false] [currentDB=] [isPessimistic=false] [sessionTxnMode=PESSIMISTIC] [sql="select current_resource_group()"][2023/06/29 11:28:09.557 +09:00] [INFO] [session.go:3878] [GENERAL_LOG] [conn=7398943596793037429] [user=u2@192.168.195.128] [schemaVersion=53] [txnStartTS=0] [forUpdateTS=0] [isReadConsistency=false] [currentDB=] [isPessimistic=false] [sessionTxnMode=PESSIMISTIC] [sql="set resource group rg1"][2023/06/29 11:28:19.532 +09:00] [INFO] [session.go:3878] [GENERAL_LOG] [conn=7398943596793037429] [user=u2@192.168.195.128] [schemaVersion=53] [txnStartTS=0] [forUpdateTS=0] [isReadConsistency=false] [currentDB=] [isPessimistic=false] [sessionTxnMode=PESSIMISTIC] [sql="select * from test.t1 limit 1"][2023/06/29 11:28:19.534 +09:00] [INFO] [controller.go:287] ["[resource group controller] create resource group cost controller"] [name=rg1]

如果真的呈现【问题三】中形容的，存在 Bad SQL “越权” 运行的状况，能够从日志中查找线索。

TiFlash 或将在将来版本中反对 Resource Control

在以后版本 (TiDB 7.1.0 LTS) 中，TiFlash 暂不反对资源管控性能，预计将在将来版本中失去反对。上面从两个试验来察看 TiFlash 组件对资源管控的调度状况，后果必定是未应用的，不过这个试验能够等将来版本公布之后再做一次，置信会失去不同的后果。

试验一：指定 SQL 从 TiFlash 读取数据，察看执行打算中的 RU 值

对试验表 t 创立 TiFlash 正本，别离从 TiKV / TiFlash 读取数据，并查看理论执行打算中的 RU 值。

-- tiflash replicaALTER TABLE t SET TIFLASH REPLICA 1;-- read from tiflashEXPLAIN ANALYZE FORMAT = 'verbose'SELECT /*+ read_from_storage(tiflash[t]) */ COUNT(*)FROM t;-- read from tikvEXPLAIN ANALYZE FORMAT = 'verbose'SELECT /*+ read_from_storage(tikv[t]) */ COUNT(*)FROM t;

SQL 执行后果如图所示，从 TiKV 读取数据的 SQL， RU 值约 40，而 TiFlash 的 RU 值则为 0，阐明以后版本的 TiFlash 并不反对 RU 的计算。

试验二：从日志中观测是否调用资源组控制器

当某个用户连贯到 TiDB 后，并向 TiDB 收回 SQL 语句，TiDB Server 向 PD 发动申请，PD 会创立（调配）一个资源组控制器 (resource group controller)，TiDB Server 会将相干信息打印到日志中，如：

... [INFO] [controller.go:287] ["[resource group controller] create resource group cost controller"] [name=rg1]

咱们能够通过剖析 TiDB Server 的日志，来观测发送到 TiFlash 的查问是否调用资源组控制器，并以此来判断 TiFlash 是否实现 RU 计算。对照试验如下：

EXPLAIN ANALYZE FORMAT = 'verbose' SELECT /*+ RESOURCE_GROUP(rg2), read_from_storage(tikv[t]) */ COUNT(*) FROM t;EXPLAIN ANALYZE FORMAT = 'verbose' SELECT /*+ RESOURCE_GROUP(rg3), read_from_storage(tiflash[t]) */ COUNT(*) FROM t;

从截图中能够直观的看到，资源控制器为下面的 SQL 创立了一个资源组生产控制器 (resource group cost controller)，资源组名称为 rg2 。而上面的 SQL 因为从 TiFlash 读取数据，所以并不会调用资源控制器创立新的资源组生产控制器。

须要留神的是，这个试验间断触发可能并不会失去想要的后果，因为源码里实现了资源组控制器实例化判重逻辑，即在本试验中，如果资源控制器曾经为用户 u2 创立了 rg2 资源组，那么间断的会话将继续延用曾经创立好的控制器，只有当超过 GC 工夫（默认 10 分钟），再次发动新会话，才会再次创立新的资源组生产控制器。

与 MySQL 的兼容性

文曾经具体列举了 TiDB 中资源管制的语法，在 MySQL 8.0 中也有 资源组 (Resource Groups) [16] 个性，具体可参考 WL#9467: Resource Groups [17] ，但 TiDB 与之的实现不同，两者并不兼容。

如果同时治理 TiDB 和 MySQL，具体应用时，须要多加辨别免得混同。

相似之处

○ TiDB, MySQL 中的资源组相干命令，“增 ( CREATE RESOURCE GROUP ) 删 ( DROP RESOURCE GROUP ) 改 ( ALTER RESOURCE GROUP ) 查 ( SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS )” 语法相近，但命令后跟接参数不同， I_S.RESOURCE_GROUPS 表构造亦不同。

○ TiDB, MySQL 均反对 Hint，能够实现语句级资源组调用。

INSERT /*+ RESOURCE_GROUP(rg1) */ into t1 values (1);

不同之处

MySQL 中资源组的线程优先级 ( THREAD_PRIORITY ) 设定，须要开启 Linux 中的 CAP_SYS_NICE 。而 TiDB 不须要。

[Service]AmbientCapabilities=CAP_SYS_NICE

TiDB 中资源组设定的 RU 是定值，而在 MySQL 中能够指定 vCPU 为范畴值，这个范畴值对应所有可用的 CPU。

mysql> select version()\G*************************** 1. row ***************************version(): 8.0.281 row in set (0.00 sec)mysql> ALTER RESOURCE GROUP rg1 VCPU = 0-1;Query OK, 0 rows affected (0.01 sec)

TiDB 中的一些 SQL 语法或函数 (Functions) 是特有的，与 MySQL 不兼容，如 CURRENT_RESOURCE_GROUP() 。

回归根源，再看 cgroup

前文提到了 MySQL 须要借助 Nice 来控制线程优先级，其实相熟 Linux 零碎的敌人都晓得 Nice 成名已久，而 cgroup 这位后来者近年逐步走入人们的视线，尤其是虚拟化、云化技术（如 Docker, Kubernetes）成熟后，cgroup 技术更是不可或缺。比方，从 RHEL 7 之后，能够间接为某个服务在 systemd 文件中设置 CPUAccounting 和 CPUShares 来管制过程对 CPU 的占用率。从 RHEL 8 开始引入了 cgroup v2，以欠缺性能，简化配置，CPU 控制参数也做了调整，变为 cpu.weight 。

于 TiDB 而言，cgroup 也早有 应用案例 [18] ，比方在 TiDB Server 的 systemd 文件中管控服务的内存配额，来管制 OOM 触发条件。另外，在 TiDB v5.0 版本，对 TiDB Server 的参数 performance.max-procs 实现逻辑做了批改，变更为“默认状况下为以后机器或者 cgroups 的 CPU 数量”，相干内容可参考 PR #17706 [19] 。

总结

因为工夫关系，对于 “资源管制 (Resource Control)” 的内容暂且就分享到这里，内容颇多，置信能读到这里的 “Ti 友” 都是真正青睐 TiDB 的。文本分享了若干具体的应用形式，也提出了若干问题，力争做到求真务实，置信对 TiDBer 有所提醒和帮忙。最初，对于 Resource Control 的摸索才刚刚开始，期待后续版本中的性能加强（比方，对超时 SQL 进行降级或停止（TiDB 7.2 中已实现），将内存等更多资源纳入 RU，用户反对绑定多资源组等），也期待更多对于此个性的生产案例分享。

参考资料

AskTUG: https:// asktug.com/
【社区智慧合集】TiDB 相干 SQL 脚本大全: https:// asktug.com/t/topic/9996 18
resource control，default resource group 文档勘误: https:// asktug.com/t/topic/1008 372/6?u=shawnyan
resource control 相干，INFORMATION_SCHEMA.USER_ATTRIBUTES 表取值问题: https:// asktug.com/t/topic/1008 437
resource control, 如何查看session级别变量: https:// asktug.com/t/topic/1008 357
resource control, I_S 权限管制问题: https:// asktug.com/t/topic/1008 596
官网文档: https:// docs.pingcap.com/zh/tid b/stable/tidb-resource-control#%E7%9B%B8%E5%85%B3%E5%8F%82%E6%95%B0
预估集群容量: https:// docs.pingcap.com/zh/tid b/stable/tidb-resource-control#%E9%A2%84%E4%BC%B0%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%87%8F
calibrate_resource: https:// github.com/pingcap/tidb /blob/v7.1.0/executor/calibrate_resource.go#L295
【资源管控】: https:// docs.pingcap.com/zh/tid b/stable/dashboard-resource-manager
“依据理论负载估算容量”: https:// docs.pingcap.com/zh/tid b/stable/sql-statement-calibrate-resource#%E6%A0%B9%E6%8D%AE%E5%AE%9E%E9%99%85%E8%B4%9F%E8%BD%BD%E4%BC%B0%E7%AE%97%E5%AE%B9%E9%87%8F
设计文档: https:// github.com/pingcap/tidb /blob/master/docs/design/2022-11-25-global-resource-control.md#distributed-token-buckets
resource control, Grafana 面板默认配置: https:// asktug.com/t/topic/1008 464
resource control, Grafana 文档内容不残缺: https:// asktug.com/t/topic/1008 693
resource_manager: add metrics for avaiable RU #6523: https:// github.com/tikv/pd/pull /6523
资源组 (Resource Groups): https:// dev.mysql.com/doc/refma n/8.0/en/resource-groups.html
WL#9467: Resource Groups: https:// dev.mysql.com/worklog/t ask/?id=9467
应用案例: https:// asktug.com/t/topic/3712 7/2?u=shawnyan
\#17706: https:// github.com/pingcap/tidb /pull/17706

公布于 2023-09-21 08:00 ・IP 属地湖北