你要自己验证这个ping值和tso wait是否相关，你可以选几个合适的ping值低的节点，直接部署一套新的。比在老的上面折腾快多了。 老的你现在已经弄得是这个样子，要调整过来，还挺花时间的。

这没用的啊，兄弟。你想啊，这个节点取tso快，其他节点取tso慢，总体还是慢的。 即使有快有慢，要让region leader 和pd leader在一个网段，ping值小于1ms，整体才会快。 简单点，所有节点ping pd小于1ms。这个tso wait就降到2-30ms左右了。

10.52.2.10，这个地址是pd嘛？你下面的图里面没有它。 需要所有的节点到pd的ping值都小于1毫秒。其他节点到pd的ping值大，这个的节点的tso wait就大。

这个速度挺好的，tso wait现在是多少？ 你上面在ping 10.52.2.10这个地址，但是我看下面的图，没有看到这个pd？

这个和到pd ping值是线性关系。只要到pd ping值大了就好不了。 除非是pd的cpu性能不够用了。

[image] 像这个图，一个集群跨了5个子网，1，2，3，136，144。 应该以136这个子网为主，把其他子网节点缩容掉，在136这个子网多开机器，扩容到136这个子网内。 没有特殊容灾需求不要跨子网。

如果你很多集群都是这样。我只能说，从一开始部署的时候就有大问题。 把子网规划好，让同一个集群在同一个子网，ping值最好不要上1ms。想办法用缩容扩容，动态调整一下。

那问题大了去了，这根本没法用。tso wait 1.12s，到pd的ping值估计都有100ms了。

上面的问题解决了吗？ 首要问题还是先把tso wait降下来，这个降不下来，瓶颈根本都没到后面。压力没传导过去。当然一直很低。 其他的监控不要看了，没有价值，就盯着tso wait优化。

你这个数据量不用管，都是数据上PB，pd的cpu性能不足以处理所有的region心跳的时候在调整这两个参数。 你这个远远没到。安心用着。 https://docs.pingcap.com/zh/tidb/stable/tune-region-performance/#region-性能调优

注册不了的，tidb的dashboard从设计上就没有考虑过和dm这个webUI整合在一起。 原因是用户可以通过nginx这类反向代理自己去做这个整合。 https://docs.pingcap.com/zh/tidb/stable/dashboard-ops-reverse-proxy/ 看这个部分，你先用nginx反向代理dashboard，再把dm的webUI代理到 {host}/dm路径上就可以了。就可以通过{host}/dm/{path}访问dm webUI，同时通过{host}/直接访问dashboard了。 如果不熟悉nginx怎么配置，问AI。

tidb的分区主要就2个功能： 1，冷热分离，可以按找分区把冷数据调度到比较差的存储上面去，节省成本。 2，删除数据快，大表直接按照分区删数据，比写个delete快很多很多。 如果你没有这两个需求，单就查询来说，不分区更好，分区表在有全局索引的情况下，查询效率才能和不分区差不多。具体看下面这个链接 https://docs.pingcap.com/zh/tidb/stable/partitioned-table/#全局索引

帖子下面有这个按钮，选择关注就可以了。 [image]

https://docs.pingcap.com/zh/tidb/stable/three-data-centers-in-two-cities-deployment/#参数配置优化 你要看看这个部分。 希望你没有弄3个子网，如果是2个子网还有救。 确保leader只在一个子网内，然后pd通过优先级也控制在这个子网内。 也就是所有的leader和pd在一个子网内，ping控制在1ms以下最好。

[image] 这个就已经不正常了。高得离谱。仅获取tso已经是慢查询了。都不用干别的。 有那个节点跨子网了？这个按我的经验，应该是某个节点ping pd leader到25ms左右了。

不错的分享

https://docs.pingcap.com/zh/tidb/stable/grafana-performance-overview-dashboard/#database-time-by-sql-phase 看看这个图

不是很高，除非盘很差，否则可以排除是compaction pending bytes的问题。

有一次rpc超时了没连上，同时期，网络有啥异常没有？