TIKV GC繁忙出见问题

🪐 TiDB 技术问题
1

image
image895×110 3.56 KB

GC繁忙 一直访问超时 怎么解决

2

你设置了什么了吗？

3

没设置 这种情况怎么办 集群一直访问超时

4

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

按照要求描述问题，有利于你更好定位到问题~

5
  1. 临时解决方案：可通过禁用 gc.enable-compaction-filter，并重启集群。
  2. 永久解决方案：升级 TiDB 集群版本，永久解决。

GC worker 误报 busy 导致 drop/truncate table 空间不回收 ​

问题描述：

在 TiKV GC worker CPU 使用率 100% 期间内，执行 drop table 或 truncate table 命令，可能遇到删除表后 TiKV 空间不回收的问题。且 GC worker CPU 下降后，后续执行 drop table 或 truncate table 依然不会回收空间。

GitHub issue: https://github.com/tikv/tikv/issues/11903

影响版本：

v5.0.6，v5.1.3，v5.2.3，v5.3.0,

排查步骤：

  1. TiDB 监控的 GC - Delete Range Failure OPM 中有持续的 send 失败，如图：

  1. TiDB 日志中确认 Delete Range 错误原因是 “gc worker is too busy”
  2. 从原理上再次确认，检查 TiKV 曾经出现过 GC worker 持续 CPU 100% 的状况。

问题原因：

TiDB 的 drop table 和 truncate table 命令会发送 unsafe destroy range 请求给 TiKV 删除一个范围的数据。

在 TiKV GC worker 繁忙时，GC worker 的 pending task 数量可能达到上限。此时如果继续向其中添加 unsafe destroy range 任务时，会错误地增加任务数量的计数器但最终没有减小。

多次这样的操作后，该计数器的值会永久性地高于 GC worker 繁忙的阈值。之后所有的 unsafe destroy range 请求都会被 TiKV 拒绝，造成 drop/truncate table 后删除数据不成功。

规避手段：

  1. 如果当前 TiKV GC worker CPU 使用率不高，可以重启 TiKV 实例重置错误的计数器，暂时规避问题。
  2. 避免在 TiKV GC worker CPU 使用率高的时候执行 drop table/truncate table 操作。

修复版本：

v5.0.7, v5.1.4, v5.3.1, v5.4.0

Bugfix PR: https://github.com/tikv/tikv/pull/11904

2 个赞
6

重启集群报这个错

image
image863×80 3.84 KB

7

参考社区的文章

8

是生产环境吗？提示worker 忙，建议查看操作系统层面的资源占用。

9

升级一下

10

是因为我的tidb5.2.3有 bug吗

11

可以尝试重启一下tidb server模块试试。