作者： TiDBer_tjdCkZ1O
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掉，这个限流方案只适用于查询业务，涉及到写入落表的业务不适用，会导致数据丢失
