为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
【概述】tikv所有节点突然负载变高，IO变高
【背景】没有操作
【现象】集群中所有TIKV节点负载突然升高，IO变高（因为我们集群是普通SATA SSD，IO本就有一点高），主要是负载变高明显
【业务影响】 业务查询变慢
【TiDB 版本】Cluster version: v4.0.9
【附件】
看了下kafka上数据情况，很正常，数据量没有变多
2 个赞
麻烦吧tidb tikv的日志发一下
3 个赞
从监控上推测应该是有慢sql
3 个赞
我都看了tikv/tidb日志都正常，日志刷的很快，有挺多慢查询、查询超时的warn错误，但我们集群应该平时也应该挺多的，因为我们没有用NVME的SSD盘，用的普通的SATA盘，整个集群IO本就不低， 或者有什么关键字您 说下我过滤 下看看吧，日志刷太快了
3 个赞
你这个gc时间这么长，应该是有影响的
2 个赞
确实是由于gc数据量过多引起的
2 个赞
之所以设置这么长时间是因为： 我们数据量比较大，用BR做数据备份，每次完事备份要时间很长，所以修改了gc时长为1个月，用BR做备份方案是：每月1号完整备份，1号后每天基于1号做增量备份，我们的业务好像只是插入数据比较多，删改更新的场景很少，这样GC数据量应该很少吧？ 新增数据也是gc的数据吗
或者有啥好的方案推荐吗？
2 个赞
那我现在只能等着gc完成是吧？ 有没有办法处理一下呢，现在业务查询很慢，超时
2 个赞
你可以尝试一下这个
这边的建议是 修改br备份修改适合的gc时间，备份完成后将gc时间调整回之前。
1 个赞
tikv-ctl --host=ip:port modify-tikv-config -m server -n gc.max_write_bytes_per_sec -v 10MB
请问下这个限制是针对每个tikv节点的限制是吧？
这个 10MB是针对监控里面的哪个指标呢？我怎么看我现在的gc 有多少？
1 个赞
抱歉没太明白您的意思，能说的再详细一些吗， 我这边的情况是：数据量挺大大概有1.5T，每次备份的时间挺长，所以修改了gc时间为1个月，然后每月1号完整的备份数据，然后1号后每天基于1号的完整备份做增量备份
这个你可以针对对应节点即可。
1 个赞
流控是针对gc写入的
1 个赞
你可以在每月1号完整备份时将gc时间调整大一些，然后备份完成调整回正常值，增量备份时一样。
1 个赞
突然不太理解了，这样增量备份能成功吗？
我理解的增量备份就是根据历史的gc数据去做的，如果我1号完整备份完了，改了gc时间正常30分钟，那他gc完了，后面的基于1号的增量备份还能成功吗？
1 个赞
br备份，我觉得你可以理解为备份分布式物理文件。gc只是在备份期间有关，并且我记得v4.0.9开始，br备份 dumpling，都不需要手动调整gc_life了。你可以查查文档
1 个赞