TiDB 版本: v8.5.1
使用tikv作为juicefs元数据，tikv服务端的tso和pd独立部署，juicefs的pd client开启以下两项配置
发现
请问这个一般是什么原因导致的呢
检查 PD 集群内部（Leader ↔ Follower）网卡、时延、丢包、防火墙；
3个pd在同一网段的，网络时延亚毫秒级别。应该不是网络问题。因为我们每个tikv集群，都有这个tso慢的问题，不知道是不是和客户端batch获取tso有关系
从现象看，follower的P99到10s基本可以断定是网络或磁盘问题，不是TiDB本身配置问题。建议按下面步骤排查：
ping和ethtool -S看有无重传。PD对网络很敏感，跨机房或千兆网很容易这样。data-dir所在磁盘，用iostat -x 1看util是否接近100%，follower写tso需要落盘，磁盘慢会直接放大时延。Follower 的 PD gRPC P50/P99 到 10 秒，TSO 慢多半出在 follower 代理而不是 leader。先关 open-tso-follower-proxy 或别让客户端打到不健康的 follower，再查该 PD 的 CPU、磁盘和到 leader 的网络。max-tso-batch-wait-interval=10ms 只会叠加等待，治不好 10 秒级延迟。
Leader 时延正常，Follower proxy P99=10s，瓶颈位于 PD Follower 向 Leader 转发 TSO 的内部链路 优先顺序： 1. 先临时关闭open‑tso‑follower‑proxy验证问题是否消失 2. 查看 PD 日志有没有 gRPC stream 断开报错 3. 调整 PD grpc 保活参数、linux 内核 tcp keepalive 4. 微调 JuiceFS max‑tso‑batch‑wait‑interval参数
我看go客户端在gettso的时候，只要大于30ms就会打印get timestamp too slow的日志了，所以我理解至少在30ms以上就属于不太健康的状态。
而leader时延p50 ms，如果是正常的时延，是否意思是批量获取场景把50ms均摊开之后会小于30ms呢？
开了Follower代理后，请求刚好打到了性能拉胯的Follower节点上，导致获取时间戳卡了10秒。
一共三个pd，2个follwer pd各项监控指标都差不多，也不能两个都拉胯吧，机器都是一样的
可能与 TSO 微服务和 Follower Proxy 同时启用有关。TSO 已经从 PD 中独立出来，而 PD Client 中的 TSO Follower Proxy 主要面向“由 PD 自身提供 TSO”的模式，与独立 TSO 微服务并不是推荐组合。JuiceFS 不是 TiDB Server，获取 TSO 时仍然需要经过 PD 这条链路，因此开启 open-tso-follower-proxy=true 后，可能会使请求转发路径变得更复杂。
建议先关闭 open-tso-follower-proxy 做一次对比测试，同时将 max-tso-batch-wait-interval 恢复为 0。后者设置为 10ms，是为了等待更多 TSO 请求合并成批次，主要用于提升高并发场景下的吞吐量，但也会主动增加获取 TSO 的等待时间。对于对元数据操作延迟比较敏感的 JuiceFS，这个设置未必合适。不过，它本身无法解释 follower 出现 10 秒级延迟的现象。
另外，follower 的 P50 和 P99 都恰好是 10 秒，这通常说明指标统计方式、请求超时设置或重试机制可能影响了结果。建议按照具体的 grpc_method 拆分查看 gRPC 指标，再确认下是否确实存在大量耗时 10 秒的 TSO 请求。可以先关闭这两个参数进行 A/B 测试；如果 get timestamp too slow 的次数明显减少，再逐项恢复参数并确认影响。
如果关闭参数后，leader 侧获取 TSO 仍然需要 30～50ms，可以排查下 JuiceFS 到 PD、PD 到 TSO 微服务之间的网络 RTT，以及 TSO 服务发现和 advertise 地址配置。
如果配置了很大的tso缓存时间，那么出现这个日志是可预期的。我们的观察是生产里一般不影响实际请求的耗时，即可能出现持续TSO获取50ms的日志，但平均tikv请求耗时仍维持在个位数毫秒的情况
问题解决了吗
还没有