当时有上万条这个报错，然后查了一下 很多日志的key表都不是同一个表 [image]

同时也会伴随着如下的日志 [WARN] [prewrite.rs:767] [“commit_ts is too large, fallback to normal 2PC”] [lock=“Lock { lock_type: Put, primary_key: 748000000000081D3D5F6980000000000000010164617933302F7261FF77732F6433307878FF7075622F32303234FF5F31305F30392F39FF6B31397969366468FF676668737236646FFF356261306B347973FF3…

异常的tikv日志 伴随着大量的 如下日志 [WARN] [scheduler.rs:1132] [“[region 2271758687] scheduler handle command: prewrite, ts: 453102623728076289, details: SchedulerDetails { tracker: TrackerToken { shard_id: 24, seq: 39744222, key: 308 }, stat: Statistics { lock: CfStatistics { processed_keys: 0, get: 1, next: 0,…

目前排查进展：确认是gc有问题 检查了 pd 中 region 信息，无空洞 region 找到相关表，但是 key 为索引，找不到索引 id 为 2 的索引。 admin check 相关表无异常 pd-ctl region check down & miss 无异常 后续操作： 尝试重建相关表。重建表后，gc清理仍然不继续推进 [image]

任务无暂停也无法删除 [image] [image] [image]

滚动重启了一下 就正常了

里面只有一个gc_worker本身自己的 所以比较奇怪

嗯嗯 我们后面也会测试一下 6.5版本

线上实例关闭 raft engine之后 效果确实明显，从数据库和业务角度都能观察到效果显著

其实从机器监控来看 唯一堵住的地方就是write_raft,不过几乎就出现在某个节点，这个节点替换后又专业到了另一个节点，怀疑是某个region更新频繁导致，从热点和机器分析都不是很明显，从慢查询角度分析的话，也没有找到可疑的慢sql

这个问题 我们跟业务一起复现了一下，确实6.1.7 开启raft engine 相关raft抖动比较大，关闭之后就正常了，但是不抖动时候确实延迟要比关闭时要好 [image]

抖动时写入sql有影响的

cpu，mem，disk io，network 这些没有抖动,目前就是raft log 抖动影响到了写入抖动

嗯 就是写raft也不是慢，偶尔有抖动

只是看到写raft 这块抖动比较严重 其他apend log这些延迟都还好

调整了 但是一样抖动 从日志相关分析来看，瓶颈好像也不在这里

[image] 就这个指标抖动比较严重

[image] 升级上来的 值为1

嗯嗯 因为升级后默认开启了 raft engine 所以也不会写raftdb了，现在还是怀疑是raft engine引擎写入又抖动，我们关闭重启看看