?insert带来的TiDB集群性能瓶颈排障( 三 ) _云知道

写写冲突在 21 日 01:15 出现了一个陡升的现象：

KV Duration
3KV duration 耗时都集中在 store 16，store 16 IP 地址为 218，并且结合 KV Error 的监控，可能从 01:15 左右开始218 就出现响应超时的报错
Erros
通过下述监控面板，server is busy直接能定位到218机器，在 raftstore error 监控面板中，01:15 左右 218 出现了大量的 not leader,这是因为region 因为冲突特别繁忙，没有办法响应请求了。

grpc
通过 grpc message count 以及 message duration 两个监控项看下，从 01:15 左右开始，整个tikv-details 处理消息的数量大幅降低，并且处理 prewrite 的耗时，翻倍上涨，整个写入速度大幅降低。

Thread CPU
raftstore cpu 以及 async apply cpu 利用率同样在 01:15 开始利用率大幅下降，与 grcp 相关监控吻合，集群此时，处理写入的速度确实降低了。

scheduler worker cpu 在 01:15 也降低了，但是 218的 scheduler 的 cpu 异常高于其他 tikv，并且出现上涨是在 00:45 左右。这是因为该节点冲突严重，scheduler在反复调度，处理pending task 。

因为上面的 scheduler worker cpu 的异常现象，排查热点相关的问题，发现在出现问题时，
各个 tikv 节点接收的消息较为均衡，热点现象排除。

Storage
查看 async write duration，发现从 01:15 开始 async write duration 非常低，故不再查看propose wait，append，apply wait 以及 apply 耗时，整个写入慢的问题不是发生在这个阶段，很可能是发生在 scheduler 阶段。rocksdb-kv 相关的监控也验证了这一点。

RocksDB – KV
查看 rocksdb-kv 中 wal 以及 write duration 自 01:15 开始耗时下降，与 storage 处的猜测吻合，不是 raftstore，apply 以及 rocksdb 慢，可能是慢在了 scheduler。

Scheduler – prewrite
接着查看了 scheduler – prewrite 监控面板，出现 command 以及 latch wait duration 逐渐上涨
的情况，与 grpc 监控 prewrite 耗时增长相匹配。此时，基本确定，写入慢是因为 scheduler-prewrite 耗时太长导致。

4
总结
问题的原因是写写冲突导致的 tikv scheduler latch 等待，并且集中在某几个 key 和region，scheduler 的 slot 有限排队等待严重，进而出现集中请求的 region 所在的tikv 很繁忙，出现 server is timeout 的报错。
处理办法：
因为写写冲突都是集中在某个 key 和某个 region 上，并且冲突比较严重，尝试开启 tidb txn-local-latches，让 latch 等待集中在 tidb，缓解 tikv 的压力。
处理结果：
调整参数后，并没有缓解。
业务逻辑：
与开发沟通后，了解到，业务端的唯一键检查主要靠数据库的 uk 来保证，应用端没有实现相关机制，当数据库报错后，业务再去做相应的报错处理。
因为这样的原因，出现某个 key 的冲突严重。但是这个逻辑在 19 年就已经有了，只是在 21 号爆发了。
可能是 21 号某种业务行为，导致某条数据，会频繁的出现，并进行 insert，写写冲突爆发。