TiDB 7.1.0 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 FORSELECT COUNT(*) FROM t1 t JOIN t1 t2 USING (uid) 
USINGSELECT /*+ 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 = 100PRIORITY = HIGHBURSTABLE;
​
-- 创建 `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] ... [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 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/999618
  3. resource control,default resource group 文档勘误: https://asktug.com/t/topic/1008372/6?u=shawnyan
  4. resource control 相关,INFORMATION_SCHEMA.USER_ATTRIBUTES 表取值问题: https://asktug.com/t/topic/1008437
  5. resource control, 如何查看session级别变量: https://asktug.com/t/topic/1008357
  6. resource control, I_S 权限控制问题: https://asktug.com/t/topic/1008596
  7. 官方文档: https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control#%E7%9B%B8%E5%85%B3%E5%8F%82%E6%95%B0
  8. 预估集群容量: https://docs.pingcap.com/zh/tidb/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/tidb/stable/dashboard-resource-manager
  11. “根据实际负载估算容量”: https://docs.pingcap.com/zh/tidb/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/1008464
  14. resource control, Grafana 文档内容不完整: https://asktug.com/t/topic/1008693
  15. resource_manager: add metrics for avaiable RU #6523: https://github.com/tikv/pd/pull/6523
  16. 资源组 (Resource Groups): https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html
  17. WL#9467: Resource Groups: https://dev.mysql.com/worklog/task/?id=9467
  18. 使用案例: https://asktug.com/t/topic/37127/2?u=shawnyan
  19. #17706: https://github.com/pingcap/tidb

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/137939.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

一个热爱自动驾驶但妥妥外行之人的思考-2023

时间节点为2023年9月,有效期当下及过往,不含未来。 这些年准确说从10年就很关注自动驾驶行业,包括物流/机器人/汽车等。 也和行业内,行业外的朋友做了大量的交流。点滴沟通放在如下链接中: 动态 - CSDN 一些过去的观…

新型智慧公厕“1+3+N”架构,平台、系统、应用的创新

近年来,随着人民生活水平的提高,人们对公共设施的要求也越来越高。其中,如厕问题一直是人们关注的焦点,但传统的公厕设施已经不能满足人们对干净、舒适、安全的需求,这促使了新型智慧公厕的诞生与应用,以如…

八月份跳槽了,历经华为测开岗4轮面试,不出意外,被刷了...

大多数情况下,测试员的个人技能成长速度,远远大于公司规模或业务的成长速度。所以,跳槽成为了这个行业里最常见的一个词汇。 前几天,我看到有朋友留言说,他在面试华为的测试开发工程师的时候,灵魂拷问三小…

c++ 纯虚函数、抽象类

一、 纯虚函数 抽象类 只要有一个纯虚函数&#xff0c;这个类称为抽象类 抽象类的特点 1、无法实例化 2、抽象类的子类&#xff0c;必须要重写父类中的纯虚函数&#xff0c;否者也属于抽象类 例子一 #include <iostream> #include <string.h> using namespa…

MySQL数据库详解 三:索引、事务和存储引擎

文章目录 1. 索引1.1 索引的概念1.2 索引的作用1.3 如何实现索引1.4 索引的缺点1.5 建立索引的原则依据1.6 索引的分类和创建1.6.1 普通索引1.6.2 唯一索引1.6.3 主键索引1.6.4 组合索引1.6.5 全文索引 1.7 查看索引1.8 删除索引 2. 事务2.1 事务的概念2.2 事务的ACID特性2.2.1…

单片机学习--->Keil多文件工程

1、在文件夹中创建新的文件夹 目录&#xff1a; App 文件夹&#xff1a;用于存放外设驱动文件&#xff0c;如 LED、数码管、定时器等。 Obj 文件夹&#xff1a;用于存放编译产生的 c/汇编/链接的列表清单、调试信息、 hex 文件、预览信息、封装库等文件。 Public 文件夹&#x…

蓝桥杯 题库 简单 每日十题 day3

01 约数个数 题目描述 本题为填空题&#xff0c;只需要算出结果后&#xff0c;在代码中使用输出语句将所填结果输出即可。 1200000 有多少个约数&#xff08;只计算正约数&#xff09;。 解题思路 枚举&#xff0c;从1开始一直到1200000本身都作为1200000的除数&#xff0c;…

Spring 6.0 新特性

文章目录 Spring的发展历史AOTGraalVMSpringBoot实战AOTRuntimeHints案例分析RuntimeHintsRegistrar SpringBoot中AOT核心代码 Spring的发展历史 AOT Spring 6.0的新特性Ahead of Time&#xff08;AOT&#xff09;编译是一种技术&#xff0c;可以提前将Spring应用程序编译成原…

JWT安全及案例实战

文章目录 JWT 安全1. Cookie2. Session3. Token4. JWT4.1 JWT概述4.1.1 JWT头4.1.2 有效载荷4.1.3 签名哈希4.1.4 通信流程 4.2 JWT 漏洞描述4.3 JWT 漏洞原理4.4 JWT 安全防御 5. WebGoat 靶场实验5.1 第四关5.2 第五关5.3 第七关 越权与逻辑漏洞 Web漏洞点只有一个入口&#…

Direct3D融合技术

该技术能使我们将当前要进行光栅化的像素的颜色与先前已已光栅化并处于同一位置的像素的颜色进行合成&#xff0c;即将正在处理的图元颜色值与存储在后台缓存中的像素颜色值进行合成(混合)&#xff0c;利用该技术我们可得到各种各样的效果&#xff0c;尤其是透明效果。 在融合…

云渲染是怎么做到不排队的

云渲染排队严重影响了用户的使用体验&#xff0c;还会导致用户的流失&#xff0c;因此解决渲染不排队的问题对于云渲染平台来说是非常重要的。而作为云渲染平台&#xff0c;自己的机器基本都是固定的&#xff0c;哪如何解决用户渲染排队的问题呢&#xff1f;我们一起来看看全国…

天地图绘制区域图层

背景&#xff1a; 业务方要求将 原效果图 参考效果图 最终实现效果 变更点&#xff1a; 1.将原有的高德地图改为天地图 2.呈现形式修改&#xff1a;加两层遮罩&#xff1a;半透明遮罩层mask区域覆盖物mask 实现过程&#xff1a; 1.更换地图引入源 <link rel"style…

免杀对抗-java语言-shellcode免杀-源码修改+打包exe

JAVA-ShellCode免杀-源码修改&打包EXE Shellcode-生成/上线 1.msf生成shellcode 命令&#xff1a;msfvenom -p java/meterpreter/reverse_tcp LHOSTx.x.x.x LPORTxxxx -f jar -o msf.jar 2.msf设置监听 3.执行msf生成的shellcode jar包&#xff0c;成功上线 命令&#xff1…

网络安全第一次作业

1、什么是防火墙 防火墙是一种网络安全系统&#xff0c;它根据预先确定的安全规则监视和控制传入和传出的网络流量。其主要目的是阻止对计算机或网络的未经授权的访问&#xff0c;同时允许合法通信通过。 防火墙可以在硬件、软件或两者的组合中实现&#xff0c;并且可以配置为根…

西部数据硬盘查询

保修状态 | WD 支持 保修状态 | WD 支持 https://support-cn.wd.com/app/warrantystatusweb https://support-cn.wd.com/app/warrantystatusweb 选择大陆

【C++】STL—— unordered_map的介绍和使用、 unordered_map的构造函数和迭代器、 unordered_map的增删查改函数

文章目录 1. unordered_map的介绍2. unordered_map的使用2.1unordered_map的构造函数2.2unordered_map的迭代器2.3unordered_map的容量和访问函数2.4unordered_map的增删查改函数 1. unordered_map的介绍 unordered_map的介绍 &#xff08;1&#xff09;unordered_map是存储&l…

Vue路由与node.js环境搭建

目录 前言 一.Vue路由 1.什么是spa 1.1简介 1.2 spa的特点 1.3 spa的优势以及未来的挑战 2.路由的使用 2.1 导入JS依赖 2.2 定义两个组件 2.3 定义组件与路径对应关系 2.4 通过路由关系获取路由对象 2.5 将对象挂载到vue实例中 2.6 定义触发路由事件的按钮 2.7 定…

JavaScript小案例-tab栏切换(可移除item)

gif效果图&#xff1a; 代码&#xff1a; <!DOCTYPE html> <html lang"en"><head><meta charset"UTF-8"><meta name"viewport" content"widthdevice-width, initial-scale1.0"><title>tab栏切…

看完100%会写毕业论文

写论文是每个学术研究者都要面对的任务之一&#xff0c;在开始写论文之前&#xff0c;准备工作是至关重要的。本文将介绍一些写论文准备工作的重要步骤&#xff0c;并且探讨如何利用AI写作大师辅助来提高写作效率和质量&#xff0c;让你看完100%会写毕业论文。 01 — 了解论文…

键盘失灵按什么键恢复?详细方法分享!

“我的电脑键盘莫名其妙失灵了&#xff0c;试了好多方法都无法恢复。请问遇到键盘失灵的情况&#xff0c;应该按什么键才能恢复呢&#xff1f;” 键盘是计算机的重要输入设备之一&#xff0c;但有时候它可能会出现失灵的情况&#xff0c;让用户感到困惑和不知所措。但其实&…