TiKV_scheduler_latch_wait_duration_seconds 频繁告警，解决方案

Raymond · 2026 年4 月 30 日 06:06

最近 TiKV_scheduler_latch_wait_duration_seconds 频繁告警，期间插入数据和更新数据很慢，时间都在prewrite 上

大家帮忙看下
背景是:有5个tikv，告警的时候，发现其中23这个tikv的毛刺特别突出，怀疑是锁冲突，

tikv-details-scheduler->scheduler writing bytes

![5275d3f25f56366f0c735fcedf4942e4|690x408]
(upload://9XVMIgRFU4SEfomCOiiP1thnRTQ.png)

tidb-TiKV-Trouble-Shooting–>Write Too Slow–>Prewrite latch wait duration

tidb-TiKV-Trouble-Shooting–>Write Too Slow–>Commit latch wait duration

疑问
1、我个人是倾向于是大批量并发写入造成锁争抢导致的，不太认为是热点
依据

因为raftstore 各个tikv 看起来还算是均衡

从tikv-details-grpc的监控图来看，更像是锁的争抢

tikv-details-Scheduler - check_secondary_locks->Scheduler latch wait duration
上面scheduler latch wait duration 值很高

tikv-details-Scheduler->Scheduler - check_txn_status

上面scheduler latch wait duration 值也是很高

并且告警时间段内的tikv 日志频繁刷这些

1157:[2026/04/29 20:51:12.510 +08:00] [WARN] [prewrite.rs:832] ["commit_ts is too large, fallback to normal 2PC"] [lock="Lock { lock_type: Put, primary_key: 748000000000059E4F5F6980000000000000030419B9BACCBA00000003800000EF7F6C3F4D0419B9BACCBA000000, start_ts: TimeStamp(465952327099482215), ttl: 3012, short_value: 017D0131, for_update_ts: TimeStamp(0), txn_size: 2, min_commit_ts: TimeStamp(465952327112327203), use_async_commit: true, secondaries: [748000000000059E4F5F6980000000000000030419B9BACCBB00000003800000EF7F6C3FF10419B9BACCBB000000, 748000000000059E4F5F6980000000000000040380000000027FBEE903800000EF7F6C3F4D0419B9BACCBA000000, 748000000000059E4F5F6980000000000000040380000000027FBEE903800000EF7F6C3FF10419B9BACCBB000000, 748000000000059E4F5F7203800000EF7F6C3F4D0419B9BACCBA000000, 748000000000059E4F5F7203800000EF7F6C3FF10419B9BACCBB000000], rollback_ts: [], last_change: Unknown, txn_source: 1, is_locked_with_conflict: false, generation: 0 }"] [max_commit_ts=465952327627178087] [min_commit_ts=465952328252915718] [start_ts=465952327099482215] [key=748000000000059EFF4F5F698000000000FF0000030419B9BACCFFBA00000003800000FFEF7F6C3F4D0419B9FFBACCBA0000000000FD] [thread_id=169]

从现有证据表明，我还是倾向于是锁冲突导致的

wbslxw · 2026 年4 月 30 日 09:56

看着像锁冲突，可以看下慢日志

菩提老祖 · 2026 年4 月 30 日 10:12

是不是存在单调递增主键或者高频更新全局状态导致写入集中到单 Region。
1、自增主键集中写入？
2、写写冲突高频发生，多个事务同时修改同一行数据?

菩提老祖 · 2026 年4 月 30 日 10:15

latch 是单机内存级的轻量同步原语，仅用于调度请求顺序；lock 是分布式事务的持久化锁，需跨节点同步。若 latch 等待时间过长（TiKV_scheduler_latch_wait_duration_seconds 异常），通常反映业务存在写入热点

Raymond · 2026 年4 月 30 日 10:27

我这边大量的写入场景是这样的，从一个在线集群同步数据到这个集群，用的就是tidb的cdc，但是在dashboard里面，表现的是begin.insert into或者begin,update
所以这种都是悲观事务，感觉latch 会对悲观事务造成影响吗

Royce1220 · 2026 年4 月 30 日 14:41

悲观事务可能会有锁争用吧

独善其身 · 2026 年5 月 1 日 02:19

看上去像是两阶段的第一个阶段就出现问题了

Augenstern · 2026 年5 月 1 日 09:06

写冲突频繁

纯白镇的小智 · 2026 年5 月 1 日 15:01

感觉也是锁冲突

TiDBer_00001 · 2026 年5 月 3 日 02:49

个人感觉：高并发写入导致的 TiKV Scheduler Latch 竞争 + 事务冲突

独善其身 · 2026 年5 月 3 日 09:42

主要是事务锁比较严重啊,没有控制好业务逻辑

Royce1220 · 2026 年5 月 6 日 14:05

估计是并发太高导致的争用

Raymond · 2026 年5 月 6 日 15:20

如果是热点，那么raftstore 应该会有体现

TiDBer_sheldon · 2026 年5 月 7 日 02:07

锁争抢也是热点的可能

hush · 2026 年5 月 7 日 07:05

热点数据集中和突发高并发写入导致的存储层竞争与IO放大，建议进一步结合slow log分析

cchouqiang · 2026 年5 月 8 日 02:05

看下sql执行的耗时，有锁冲突的耗时

zhanggame1 · 2026 年5 月 8 日 07:16

这种问题最好从业务入手看看怎么解决

Royce1220 · 2026 年5 月 8 日 14:29

看看业务是不是并发写入热点有点多

Raymond · 2026 年5 月 9 日 05:52

这个不是业务导致的，这个是从上游的在线的tidb集群通过cdc 导入到下游的离线的tidb 集群

zhanggame1 · 2026 年5 月 11 日 06:25

同步延时多少，cdc同步如果有有大的事务产生很多dml语句，这个现象是合理的，忽略掉