raft client wait connection ready duration过大导致的prewrite延迟过高

[TiDBeeBEE (Ti D Ber Fq La Kqlg)]

TiDB 版本：v8.5.1

使用tikv作为juicefs的元数据，业务大量删除文件导致prewrite和commit的QPS升到20k，进而发现prewrite和commit的时延暴涨，进一步排查发现是raft client wait connection ready duration过高导致，reload之后一切恢复了，但是不知道具体的是什么导致的。

排查流程如下

1. prewrite和commit的QPS升到2w，时延暴涨到15ms
   

   

2. storage async write duration接口时延较高，应该是raft store的接口慢了
   

   

3. raft store内部的store commit and persist duration较高
   

   
   
   但是store commit but not persist duration不算高
   
   
   
   其他环节比如append log等时延也不高
   
   
   
   
   

到这里怀疑是raft网络的问题
4. 发现raft client wait connection ready duration较高，此前这个指标一直都是空的

5. 对tikv实例逐个reload后，问题消失，prewrite的时延下降，并且可以支持更高的QPS，也不会出现上面的问题

按照自己上面的分析，是tikv的commit log阶段，raft leader和follower之间的grpc链接等待时间较长，导致raftstore的async write接口慢了，最终导致prewrite和commit接口慢了。

但是只能分析到这里了，不知道为什么这个raft client connection的等待时间会变长，也不知道下一步具体要怎么排查。

请教各位专家

1. 上面的分析是否正确
2. 下一步要怎么具体分析

========> 20260819 发现了 3个新的线索！！！

感谢各位专家的解答

经过进一步分析监控和日志，有3个新的发现

1. 故障期间有两个异常指标，这两个指标在非故障场景是没有的
   resolve address duration较高
   
   
   
   server report error(unreachable-to-xxxxxx)较高
   
   

我看了下tikv的代码，这两个指标，以及raft client wait connection ready duration这个指标，都是在同一个函数里面的，函数如下，这个函数应该是为每一个对端store维护raft连接池的

2. 查看故障期间日志，发现较多的因为keepalive tiimeout导致的connection abort ERROR
   [ERROR] [raft_client.rs:585] [“connection aborted”] [addr=xxxx] [receiver_err=“Some(RpcFailure(RpcStatus { code: 14-UNAVAILABLE, message: "keepalive watchdog timeout", details: }))”] [sink_error=“Some(RpcFinished(Some(RpcStatus { code: 14-UNAVAILABLE, message: "keepalive watchdog timeout", details: })))”] [store_id=11140474] [thread_id=8]

[ERROR] [raft_client.rs:904] [“connection abort”] [addr=xxxx] [store_id=11140474] [thread_id=471]

3. 故障期间的threads cpu
   发现import cpu在故障期间和非故障期间差距极大，在故障期间虽也只有2%左右，但是reload恢复后只有0.02%。并且集群恢复后我们再次开启文件删除，prewrite和comit的qps再次拉高，但是没有复现问题。import cpu也一直维持0.02%的水位。
   这个指标应该是tikv store导入snapshot的操作。
   
   

结合以上的线索，我是否可以这样推测

1. 业务发起unlink，触发tikv的prewrite+commit qps较高
2. 因为raft client的一些问题，导致raft client connection时延较高
3. 此时raft leader和follower同步较慢，启动snapshot机制来同步
4. snapshot也要使用raft client来传输数据，进一步恶化raft client链接问题
5. 陷入恶性循环，导致raftstore的async write接口持续居高不下，影响业务接口时延
6. 业务停止删除，prewrite qps下降，但是时延依然居高不下，因为恶性循环依然存在
7. reload tikv，系统状态重置(链接，队列，在途snapshot，stream窗口)，循环被打破，恢复正常

reload恢复之后，即便再次开启juicefs删除，prewrite的qps变得更高，时延也依然很低，上面的各种异常指标都没有再升高，怀疑是没有陷入恶性循环？

请教专家，这种分析是否合理？如果合理，这种问题的触发场景可能是什么呢，如何杜绝，如何进一步排查？感谢

[wbslxw (Ti D Ber Cl S0j Eng)]

分析的有道理，
TiKV Raft Client gRPC 连接池上限不足
监控 TiKV 指标： tikv_raft_client_grpc_conn_pool_conn_num 观测故障时段：连接数是否贴近上限。

[TiDBeeBEE (Ti D Ber Fq La Kqlg)]

这个指标没看到啊，具体位置在哪里

[kang]

从你的排查路径看，问题定位很清晰，raft client wait connection ready duration 高基本就是 gRPC 连接池没就绪导致的。这类问题常见原因有两个：

1. 连接池被耗尽：20k QPS 下大量 raft 消息挤占连接，加上 TiKV 默认 grpc-concurrency 可能不够，连接建立跟不上。

[TiDBer_bawpguhQ]

reload 能恢复，说明是 Raft gRPC 连接池里有卡住的连接，不是算法本身坏了。JuiceFS 大批量删除把 Raft 流量打高后，等连接就绪的时间会暴露出来。建议查节点间网络和 keepalive，并观察 raftstore CPU、落盘和 follower 是否在掉连接。

[独善其身 (Ti D Ber Bi Rqfz5 K)]

JuiceFS 大量删除元数据，瞬间爆发海量小事务，Region 读写风暴 → TiKV 节点之间 raft 消息并发突增 → raft‑client 内部 grpc 长连接出现部分连接静默断开 (TCP 已经断，但是 grpc 连接池还标记为可用)、连接池队列阻塞 → 新的 raft 复制请求需要等待可用连接：raft client wait connection ready duration飙升 → raft 同步延迟升高 → Leader 无法快速拿到副本 ack，store commit&persist 变慢 → prewrite/commit 事务阻塞、时延暴涨 → reload 重启 tikv，全部 grpc 连接销毁重建，僵死连接被清除，故障消失

重点指标解读 raft client wait connection ready duration：请求已经准备好，但是拿不到可用 gRPC 连接，处于等待连接就绪状态。 该指标不为 0 = 瓶颈在raft‑client 侧连接管理，不是 follower 处理慢，也不是单纯网络 RTT 高。

[TiDBeeBEE (Ti D Ber Fq La Kqlg)]

多谢，进一步排查tikv日志，看到了keepalive timeout然后connection abort的ERROR，在问题中左了详细更新，帮忙在看看~

[TiDBeeBEE (Ti D Ber Fq La Kqlg)]

node exporter的磁盘写入时延在故障期间都是正常的。
看日志发现了keepalive timeout 的connection abort问题，在问题中更新了新的线索。

[TiDBeeBEE (Ti D Ber Fq La Kqlg)]

@独善其身

prewrite

多谢回复。
我在问题中更新了几个新线索，帮忙再看看，感谢！

另外：对于这种情况，原理上我理解是可以解释的，但是好像也不是每次都出现，而是偶发的，比如只有这个tikv集群出现过，并且reload之后再次开启删除再没有遇到(而且删除的qps更高，时延更低)。所以是否有什么特殊的情况，会触发呢？