tidb层 PD TSO Wait Duration 999指标达到了 20 ms级别

【 TiDB 使用环境】线上
【 TiDB 版本】5.3.1
【遇到的问题】
PD延时

PD 本身自己处理是很快的

tidb 层cpu 不均衡
image

上面蓝色的线是个什么 CMD ? 感觉有峰值

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就可以了。

999-wait

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的延迟

没看到有相应指标