get timestamp too slow ---v3.0.7

[llplmlyd]

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

• 【TiDB 版本】：v3.0.7
• 【问题描述】：执行简单的创表以及授权语句都需要很长时间。
  
  
  
  查看tidb日志中有大量的get timestamp too slow
  
  
  
  PD日志中也存在
  
  

看了一些其他的帖子
1.网络延迟 应该不存在：tidb与pd部署在同一台机器上，应该是不存在网络延迟的问题
2.用户使用了分区表 根据字段的hash分区
3.PD的各项指标都比较高

CMD Duration

TSO RPC Duration

4.tidb、pd所在机器uptime负载情况
11:17:35 up 240 days, 1:47, 2 users, load average: 21.31, 19.99, 20.03

5.机器部署情况

6.硬件情况
tidb 40s 125GB

7.数据量 12.9GB region数量 10w+

[来了老弟]

你好，
此报错时 tidb 到 pd 拿 tso 超时，可能是 tidb 到 pd 的网络卡了，也可能是 pd 卡了。

排查：
TiDB 监控面板上的 pd client 监控中的截图，来定位不是 TiDB 节点卡了。
pd 的监控已经上传，duration 均很高。

根据当前的数据量 12.9gb 有 reggion 10w，可以上传下 tikv-detail 中 leader 和 region 的监控截图和 region health 的监控截图。

请务必上传完整。感谢配合，这边会积极解决你的问题

[来了老弟]

hi，

请问下目前问题是否已经得到解决了呢

[llplmlyd]

没有哈 近期多个集群 出现性能问题，继续跟进

[llplmlyd]

tikv-detail 中 leader 和 region 的监控

region health 的监控

望老师回复

[来了老弟]

先进行下 region merge 吧，空 region 数量比较多，可能会给 pd 造成负担，可以在 asktug 搜索下。

[llplmlyd]

好的 我试试，是为啥会造成这么多空region，频繁的删除创建吗？

[来了老弟]

当大量删除数据后会留下很多小 region ，目前统计是小于 1M 的 region 都会被监控到，table 级别的 region 不会自动合并，所以可能是在 drop table / database 时会有此现象。

[llplmlyd]

经过调整之后region数量有了大幅度的下降，并且空region数量也下降了很多，业务反馈集群速度恢复正常:clap:

[来了老弟]

666，感谢反馈，有问题欢迎开新帖继续讨论哈。