【 TiDB 使用环境】线上
【 TiDB 版本】5.3.1
【遇到的问题】
PD延时
PD 本身自己处理是很快的
tidb 层cpu 不均衡
TiDB 侧拿到一个 TS 后（TSFuture），调用其 Wait 方法获取 TSO 的等待时长，即“调用 tsFuture.Wait() 到获取到 TSO 结果的时长“。
当 TiDB 请求生成 TSO 时，PD Client 不会 block 调用者，而是直接返回一个 TSFuture，并在后台异步处理 TSO 请求的收发，一旦完成立即返回给 TSFuture，TSFuture 的持有者则需要调用 Wait 来获得最终的 TSO 结果。此时分为两个情况：
- 如果 TSO 请求已经完成，Wait 会立刻返回一个可用的 TSO 或 error
- 如果 TSO 请求还未完成，Wait 会 block 住等待一个可用的 TSO 或 error（说明 gRPC 请求在途，网络延迟较高）
而 PD TSO Wait Duration 就代表了从调用 Wait 方法到获得 TSO 的总等待时长（不包括 error 的情况），其可能包括了以下耗时（注意这个“可能”，具体会因调用 Wait 的时机不同而变化）：
- TiDB 侧 Go Runtime 调度耗时（大多数情况）–tidb cpu
- 部分 gRPC 网络时延
- 部分 PD 侧 TSO 生成处理耗时
- 部分 PD 侧 Go Runtime 调度耗时
1 个赞
这个有峰值是正常的吧。数据库各指标、压力也是随着业务请求情况有波动的。如真的平静如水，那估计用台mysql就可以了。
TSO Wati 一般是 tidb 获取到 tsFuture 后，处理的时间
通过 别的方式指导一下，让 tidb 的链接和资源平衡点…
那意思是这个指标大一些也没问题是吗，最好官方出个标准范围就好了
这个意思是， TSO 慢，是因为 tidb 无更多的资源应答这块的处理了，所以慢
通过 PD TSO 处理 和 RPC 网络传递的延时，可以判断并不是 PD 的问题
这个延时是否会影响业务，也是判断条件之一了
大佬比较建议从tidb侧排查是吧，我们是从4.0迁移数据到5.3.1的，机器配置都是一致，某些指标慢了有些奇怪就上来问问
网络和PD处理延迟比较低，主要在tidb侧，看下 TIDB的Async TSO Duration parse compile的延迟
没看到有相应指标
您好，请提供 blackbox exporter 监控面板，instance 选到 pd leader 并标注出来 tidb-server 节点的 IP。