为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】 tidb 4.0
【概述】场景+问题概述
【背景】做过哪些操作
【现象】业务和数据库现象
【业务影响】
【TiDB 版本】tidb4.0
【附件】
- 相关日志 和 监控
-
TiUP Cluster Display 信息
-
TiUP Cluster Edit Config 信息
-
TiDB- Overview 监控
- 对应模块日志（包含问题前后1小时日志）
【业务影响】
【TiDB 版本】tidb4.0
【附件】
麻烦提供一下文本 log,图片最近打不看,不清楚 
图片看不清楚，可以重新贴一下原图吗？
1.麻烦反馈下具体的 tidb 集群版本，以及在报错开始前是否对集群做过什么操作；
2.从日志中看报错提示的是固定的某几个 region ，可以先看下具体的 region 状态：
（1）查看下 region 状态是否正常：
tiup ctl:<cluster-version> pd -u <pd_ip:pd_port> region <region_id>
（2）如果 region leader 和副本状态均正常，可以看下 region 的mvcc.num_rows 是否很多：
tikv-ctl --host <tikvip>:<tikvport> size -r <region_id>
tikv-ctl --host <tikvip>:<tikvport> region-properties -r <region_id>
（3）若 num_rows 也很多，看下当前集群的 gc 配置是否很长：
select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like "tikv_gc%";
如果上面几条内容都满足的话，可能是一个已知的 bug ，可以降低 gc 时长看下效果
update mysql.tidb set VARIABLE\_VALUE="xxx" where VARIABLE\_NAME="tikv\_gc\_life\_time";
1 个赞
图片点击得了了~
这是region不存在吧？
这里 tikv_gc_life_time 设置为 720h 确实有点太长了，不知你这边设置这么大的原因是什么，现在可以考虑逐步减少 tikv_gc_life_time 的值，将过旧的 region 版本数据清理掉，这个问题应该会有所缓解。
tikv_gc_life_time 这个参数修改小了会影响保留数据时长吗？
会影响的，不建议将该值设置的过大，保留了太多了旧版本数据会对集群的性能有明显的影响，具体 GC 机制可以参考下：https://docs.pingcap.com/zh/tidb/v4.0/garbage-collection-overview#整体流程
是不是热点问题造成的？现在有两张上亿的大表在批量写入。现在GC调整多久合适？
1.这个跟热点有一定关系，但主要还是 GC 时间设置的时间太长导致积累了大量旧版本的数据，放大了这个问题；
2.GC 调整为多久（即能查看多久前的旧版本数据）需要看你们业务以及运维的需求，但不建议一下子将时间调整的很小，防止因短期内删除大量旧版本数据引起集群性能的波动，可以适当进行下流控：
（1）gc 限流
tikv-ctl --host=ip:port modify-tikv-config -n gc.max-write-bytes-per-sec -v xxxMB
（2）rocksdb 流控
参考 https://docs.pingcap.com/zh/tidb/v4.0/tidb-troubleshooting-map#43-客户端报-server-is-busy-错误 中 4.3.1 章节
（3）调低 pd 调度参数
store-limit 适当调小
1 个赞
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。