storage async snapshot duration过高如何排查

🪐 TiDB 技术问题 性能调优
1

【 TiDB 使用环境】
生产环境

【 TiDB 版本】
v5.1.2

【复现路径】
集群总共4台kv机器，总共20T数据，drop掉了3T的表，然后集群中其中1台kv节点一直指标异常，持续了半个月，表现为：

  • CPU正常，每个线程均未打满
  • apply log duration过高(达到秒级)
  • storage async snapshot duration过高
  • IO正常
  • 物理机磁盘写入延迟正常
  • Rate snapshot message为0，而其他机器均为几十
  • 99.99% snapshot KV count为0，而其他机器均为1.5Mil
  • Approximate Region size为2G，其他机器均为200MB

目前只要压力一增大，就会出现slow query。slow query耗时1.3s左右，其中prewrite阶段耗时1.3s

【资源配置】
500MB/s SSD
32C256G

2

目前发现好像是region分裂有问题，异常的这台机器，region从drop表以后，大小就一直在增长，其他机器region大小比较稳定

3

可以tiup install diag 安装clinic，然后收集一段时间内的数据上传
参考这个：

4

一般大表不建议直接drop，可以先truncate掉，就可以释放空间。

5

数据采集脱敏过程比较复杂，涉及到其他国家的金融监管了

7

我这边发现从drop大表开始，出现几十K的空region减不掉，并且这台机器的region大小就一直在增长，kv log也没啥报错，怀疑是因为region过大，打snap遇到了问题

目前异常的那台机器，手动连续重启了几次，现在已经彻底GG，只能当leaner。而且上面有几百个DOWN状态的Region

pd一直尝试把leader迁移到他身上，他自己接到迁移请求后正常做迁移操作，然后说自己term比对方低，一直成为follower，就没有然后了。

好处就是集群整体性能恢复正常了，我这边把那个异常节点销毁重建试试。

感觉像是直接drop大表，遇到了奇怪的问题

8

最新进展，发现DOWN状态的region是一直在尝试将异常机器添加为leaner，然后10min超时，过一段时间再次尝试

pd自始至终日志里没有尝试过将异常机器选举为leader，我继续再看看为啥

9

max-store-down-time

  • PD 认为失联 store 无法恢复的时间，当超过指定的时间没有收到 store 的心跳后，PD 会在其他节点补充副本。
  • 默认值：30m
10

发现不知道为啥会有这个调度器驱逐了节点4的全部leader，我继续查下

» scheduler show
[
“balance-hot-region-scheduler”,
“balance-leader-scheduler”,
“balance-region-scheduler”,
“label-scheduler”,
“evict-leader-scheduler”
]

» scheduler config evict-leader-scheduler
{
“store-id-ranges”: {
“4”: [
{
“start-key”: “”,
“end-key”: “”
}
]
}
}

11

看到个帖子，应该是重启时候，重启太慢，然后超时，这个evict一直没被删掉

现在因为异常节点上有一批DOWN状态的region，在解决之前决定还是不要让他被region调度为leader

13

怀疑timeout跟这个帖子一个问题，我们有个字段是大json，导致一直operator timeout，这个有办法调整超时时间么？

14

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。