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

46次阅读

共计 14380 个字符，预计需要花费 36 分钟才能阅读完成。

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。

-- CREATE
CREATE USER u3 RESOURCE GROUP rg3;
-- ALTER
ALTER 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 管制是否应用基于资源组配额的申请调度。

查看办法如下：

-- tidb
SHOW VARIABLES LIKE "tidb_enable_resource_control";
-- tikv
SHOW 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] ... 
...[INFO] [session.go:3878] ... 
...[INFO] [session.go:3878] ... 
...[INFO] [session.go:3878] ... 
...[INFO] [session.go:3878] ...

此外，这款估算模型是基于 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] 
[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] 
[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] 
[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] 
[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 replica
ALTER TABLE t SET TIFLASH REPLICA 1;

-- read from tiflash
EXPLAIN ANALYZE FORMAT = 'verbose'
SELECT /*+ read_from_storage(tiflash[t]) */ COUNT(*)
FROM t;

-- read from tikv
EXPLAIN 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);

不同之处

  1. MySQL 中资源组的线程优先级 (THREAD_PRIORITY) 设定，须要开启 Linux 中的 CAP_SYS_NICE。而 TiDB 不须要。
[Service]
AmbientCapabilities=CAP_SYS_NICE
  1. TiDB 中资源组设定的 RU 是定值，而在 MySQL 中能够指定 vCPU 为范畴值，这个范畴值对应所有可用的 CPU。
mysql> select version()\G
*************************** 1. row ***************************
version(): 8.0.28
1 row in set (0.00 sec)

mysql> ALTER RESOURCE GROUP rg1 VCPU = 0-1;
Query OK, 0 rows affected (0.01 sec)
  1. 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，用户反对绑定多资源组等），也期待更多对于此个性的生产案例分享。

参考资料

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

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

正文完
tidb
发表至： tidb
2023-09-21
 0
关于tidb:TiFlash-源码阅读一-TiFlash-存储层概览
关于tidb:深入解析-TiFlash丨多并发下线程创建释放的阻塞问题
关于tidb:21-天-TiDB-40-课程追剧挑战快速掌握-40-基础运维知识
关于tidb:TiDB数据库管控平台TiEM初体验