tidb7.5.1 压测

作者： TiDBer_tjdCkZ1O 原文来源：https://tidb.net/blog/ca242a05

Tidb7.5.1 资源隔离功能压测总结

一、压测数据库架构

二、压测功能：

1、资源隔离限制：

创建 rg2 资源组，RU(TiDB 对 CPU、IO 等系统资源的统一抽象的计量单位，用于表示对数据库的单个请求消耗的资源量) 的回填速度是每秒 60 RU。在系统资源充足的时候，不允许这个资源组的应用超额占用资源。

2、查询限制：

修改 rg1 资源组，对超过 10 秒的查询标记为 Runaway Query 并直接终止，并且在接下来的 10 分钟里，把相同模式的查询直接标记为 Runaway Query。

三、资源隔离压测结论：

1、 结论：

资源隔离限制功能符合预期。

2、 功能使用特征：

开始压测过程中负载打满，开启资源隔离限制后，需要手工 kill 正在运行的会话。当请求再次到达数据库后，资源隔离才会生效。关闭资源隔离自动释放资源限制能力。

3、 压测过程如下图所示：

四、查询限制压测结论：

1、结论：

查询限制功能符合预期。

2、功能使用特征：

开始压测过程中负载打满，开启查询限制后，根据策略自动对超过 10 秒的查询进行 kill 并保持 10 分钟内保持改策略，10 分钟后再次收集查询信息。查询时间限制和采样时间可以在资源组中灵活定义。全程无需手工介入参与。

3、压测过程如下图所示：

五、业务层面压测过程和结果

压测业务：某具体业务的汇总查询

业务压测结论：

1、TIDB 端限流有效，发压端吞吐量在开启和关闭有明显起伏，开启后可以打到限流效果，放开后可以恢复正常业务

2、限流对上游业务一侧影响不大，开启和关闭 业务预发布两台应用基本平稳

3、限流会造成业务接口延时，上游应用服务会出现线程池积压 (dubbo 线程池积压，http 请求慢响应等连锁反应)

4、TIDB 限流不会影响其他数据库用户产生影响，但是 tidb 自身会出现 sql 执行延时

5、TIDB 限流后，原积压的会话需要 DBA 手动介入 kill 掉，这个限流方案只适用于查询业务，涉及到写入落表的业务不适用，会导致数据丢失