tikv 集群版本 v8.1.0 三副本 pd tikv-server 独立部署

TSO 达到10s


pd-leader cpu 长期处于60%左右

grpc

etcd



集群什么规模,抓一下pd的火焰图看一下吧

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面

看一看你这一页的情况~

什么配置?

部署在虚拟机上的吗?

实例


主机

磁盘

存储拓扑

部署在云上的机器


三个pd 是4c8g
三个tikv-server 是16c32g

1 个赞

抓一下 172.30.208.29 这台 PD 的 profile。这台 CPU 最高
另外,请下载一下原始 profile 上传上来。截图不好看

172.30.208.20 是另一个集群pd 都有同样的问题,下面的是抓取的profile
profiling_2025-03-28_10-58-46.zip (1.0 MB)

CPU profile 看着没什么问题

从目前已提供的信息,有一个疑点是 etcd 写延迟导致的。可以把 PD 的 etcd “99% Handle transactions duration” PromSQL 里的 0.99 改成 0.999999,然后与 TSO 的延迟对照,看是否相关

如果不是这里的原因,就只能在更大范围的数据里寻找线索了。建议提供 2~3 天的 PD 监控和日志,其中覆盖 2~3 次 TSO 延迟达到 10s 的情况。可以通过 clinic 采集,参考 https://asktug.com/t/topic/272957

1 个赞



这个是改完之后的对比

改完之后三小时的


目前我们这个挺频繁的,所以只收集的24小时之前的,是足以覆盖2~3次TSO 10s
采集的链接如下:

看起来只是统计指标的问题

这个面板里看到的 TSO 处理延迟是正常的,而且数量也合理

(面板的名字虽然是 TiDB,但实际上是 PD server 自己的统计)

但 gRPC 这个统计的 TSO 请求数量是不合理的

这里 gRPC 的指标是 gRPC 框架自己的上报,并不是 PD 的代码实现。估计是哪里没有正确初始化

所以,忽略 gRPC 这个面板就好。从 TiDB 这里看 TSO 相关的指标