# [KB]关于 TiDB 集群 duration 突然打高，999 duration 打高到 1 min 左右

## Issue

集群duration在凌晨0点左右突然打高： 

![know-issue-tidb-duration-latency-1min](/images/TiDB/know-issue-tidb-duration-latency-1min.png)

集群包含 80 个 TiKV 节点，故障发生时包含100万 Regions。业务类型为大量batch插入，少量读。每天凌晨1点批量插入new partition 操作，每天凌晨4 点会 drop 历史分区。

## Root Cause

大量的写入导致产生了大 region，但是 region 分裂不及时，从而生成 snapshot 花费较长时间，并且该 region 持续分裂，导致生成的 snapshot stale 了，进而 learner 的日志一直追不上，最终导致该热点调度超时。

## Diagnostic Steps

1. 2021/06/28 00:00 集群开始往 new partition 写数据，同时duration 开始明显上升。

2. 10:00 发现问题后，进行了如下操作尝试解决: config set merge-schedule-limit 32 config set replica-schedule-limit 128 config set max-snapshot-count 64

3. evict leader 264941063 store delete 264941063 tiup stop 264941063 直接停掉进程

4. 11:45 尝试解决无果后，寻求技术支持 14:20 在给热点tikv 节点增加驱逐leader (10.0.216.210): scheduler add evict-leader-scheduler 53 ，并尝试了 operator add transfer-region 、transfer-leader 发现有部分region leader 无法手动调度走。 15:17 经确认，该集群之前添加过 tiflash 组件，目前已下线并不再使用，因此关闭 enable-placement-rules 配置 （config set enable-placement-rules false） 15:58经同意暂停了业务写入，以便快速分散调度热点 16:55 通知业务恢复业务，duration 基本恢复正常。 17:36 收集日志及监控信息 19:30-20:30 TiDB 监控有个别schema error告警，随后自愈。

5. 2021/06/29 10:50 发现pd 监控中 empty region 并没有再凌晨增加，经研发老师排查是 28日故障排查期间select ddl_jobs 查询阻塞了gc 的完成。（经确认ddl jobs 读取慢属于bug，已在4.0.11修复） 13:25 手动kill 阻塞会话的session 连接，gc正常执行，empty region 174k左右 14:35 恢复 merge-schedule-limit 120 15:30 duration 又有明显增高，经业务方确认是 业务调整造成。

6. 2021/06/30 09:20 pd监控 empty region merge 速度发现较之前慢 11:18 经研发老师排查后将 merge-schedule-limit 调整到 200

## Resolution

1. 调大 raft-log-gc-count-limit 和 raft-log-gc-size-limit，减少 stale 的情况，负面影响是可能会影响写入的性能，风险较大； 
2. 升级tidb v4.0.13，4.0.13 对 split 速度进行了优化，防止大 region 的出现，可以缓解该现象，详见 PR：[https://github.com/tikv/tikv/pull/9897](https://github.com/tikv/tikv/pull/9897)

## Workaround

N/A