资源管控管理后台任务测试效果不符合预期

【 TiDB 使用环境】
测试环境

【 TiDB 版本】
v7.5.0
tiup playground 起的本地集群 1 tidb+1pd+1tikv,只是测试功能,不涉及性能测试。

【复现路径】
【遇到的问题:问题现象及影响】
测试预期目标:
前端任务和后台任务用的都是 default 资源组。

当一种任务被标记为后端任务时,TiKV 会动态地限制该任务的资源使用,以尽量避免此类任务在执行时对前台任务产生影响。 通过设置自动识别后端任务,并降低其资源消耗。

1.tiup启动本地集群,资源管控已开启。
mysql> show variables like ‘tidb_enable_resource_control’;
±-----------------------------±------+
| Variable_name | Value |
±-----------------------------±------+
| tidb_enable_resource_control | ON |
±-----------------------------±------+
1 row in set (0.01 sec)

TiKV 参数 resource-control.enabled 没有修改,使用的是默认值 true。

2.准备测试数据,使用lightning验证后台任务是否生效
tiup bench tpcc -H 127.0.0.1 -P 4000 --user app_oltp -D tpcc --warehouses 100 --threads 20 prepare
tiup dumpling -u root -h 127.0.0.1 -P 4000 -B tpcc --filetype sql -t 8 -o ./tpcc_data -r 200000 -F 256MiB
3. lightning导入,验证没有设置后台任务的情况
mysql> SELECT * FROM information_schema.resource_groups;
±---------±-----------±---------±----------±------------±-----------+
| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | BACKGROUND |
±---------±-----------±---------±----------±------------±-----------+
| default | UNLIMITED | MEDIUM | YES | NULL | NULL |
| rg_olap | 400 | MEDIUM | YES | NULL | NULL |
| rg_oltp | 1000 | HIGH | YES | NULL | NULL |
| rg_other | 100 | MEDIUM | NO | NULL | NULL |
±---------±-----------±---------±----------±------------±-----------+
4 rows in set (0.01 sec)

tiup tidb-lightning -config tidb-lightning.toml
4.导入完成,等待几分钟集群稳定后。删除导入的数据。
5.设置lightning导入为后台任务
mysql> ALTER RESOURCE GROUP default BACKGROUND=(TASK_TYPES=‘lightning’);
Query OK, 0 rows affected (0.15 sec)

mysql> SELECT * FROM information_schema.resource_groups;
±---------±-----------±---------±----------±------------±-----------------------+
| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | BACKGROUND |
±---------±-----------±---------±----------±------------±-----------------------+
| default | UNLIMITED | MEDIUM | YES | NULL | TASK_TYPES=‘lightning’ |
| rg_olap | 400 | MEDIUM | YES | NULL | NULL |
| rg_oltp | 1000 | HIGH | YES | NULL | NULL |
| rg_other | 100 | MEDIUM | NO | NULL | NULL |
±---------±-----------±---------±----------±------------±-----------------------+
4 rows in set (0.01 sec)

tiup tidb-lightning -config tidb-lightning.toml

6.等待导入完成,观察资源消耗情况

7.结论:后台任务没有生效,无论是否设置后台任务,lightning消耗资源几乎一致,对前端任务影响还是比较大
8.继续验证 其他场景,也有类似结论。
mysql> ALTER RESOURCE GROUP default BACKGROUND=(TASK_TYPES=‘lightning,stats,ddl,br’);
Query OK, 0 rows affected (0.27 sec)

mysql> SELECT * FROM information_schema.resource_groups;
±---------±-----------±---------±----------±------------±------------------------------------+
| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | BACKGROUND |
±---------±-----------±---------±----------±------------±------------------------------------+
| default | UNLIMITED | MEDIUM | YES | NULL | TASK_TYPES=‘lightning,stats,ddl,br’ |
| rg_olap | 400 | MEDIUM | YES | NULL | NULL |
| rg_oltp | 1000 | HIGH | YES | NULL | NULL |
| rg_other | 100 | MEDIUM | NO | NULL | NULL |
±---------±-----------±---------±----------±------------±------------------------------------+
4 rows in set (0.01 sec)

1)ddl 通过 add index 后台任务,也是是否设置后台任务,没有优化
2)stats 通过 analyze 一张3300万行的表,设置后台任务也没有优化,甚至还出现更加挤兑前台任务资源情况,导致前台任务可用资源急剧下降,如下图:

官网:
https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control#管理后台任务

问题:
1.实际结果不符合预期,有哪些关键配置遗漏吗?
2.其他大佬有无测试过类似功能,是否有相同的现象,如何解决?

其实我觉得资源管控平时不需要开
为啥呢 mysql的分库分表可能大部分cpu占1%都没到
还不能自动扩容 把自动扩容开启就好了

| default | UNLIMITED | MEDIUM | YES | NULL | TASK_TYPES=‘lightning,stats,ddl,br’ |

我的理解是这样的。
TASK_TYPES=‘lightning,stats,ddl,br’是指这几类任务最后会被指定到这个资源组default 。而这个资源组default 的限制是UNLIMITED 。所以其实和没有限制一样。

可以考虑把这个几个任务分配到rg_olap资源组上,再看看结果如何。

ALTER RESOURCE GROUP rg_olap BACKGROUND=(TASK_TYPES=‘lightning,stats,ddl,br’);

“目前,所有资源组的后台任务默认都会绑定到默认资源组 default 下进行管控,你可以通过 default 全局管控后台任务类型。暂不支持将后台任务绑定到其他资源组。”

官方限定了只能放在default下

1 个赞

还没测
当前情况下我觉得应该限制下default的RU_PER_SEC和PRIORITY才合理

1 个赞

前端任务和后台任务用的都是 default 资源组么

是的,前端任务和后台任务都是在 default 资源组下面,而且整个集群没有其他任务,其他资源组也没有使用。

Resource Control 的 background 任务管理功能是基于 tikv 的 CPU/IO 的资源利用率动态调整后台任务的资源配额工作的,因此依赖在部署集群的时候设置正确的 quota. 如果在单个节点需要混合部署多个 component 或 instance, 需要通过 cgroup 对各个 instance 设置合适的 quota. 所以建议有条件的话,最好使用 tiup cluster 部署正常的集群进行测试,像调度等对集群资源敏感的功能,通常很难在 playground 环境表现的很好。

4 个赞

多谢老师回答。

使用 playground 想法是基于它做一些功能方面的快速验证,不过确实可能会有混部、单机等因素带来的干扰。
基于tikv的 CPU/IO资源使用测试的场景,还是在完整集群验证好一些

你使用的是单机模拟,得出的测试情况很难模拟出真实效果的

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。