tidb日志报gc work is too busy，查询gc safe time正常，但是查询gc_delete_range/gc_delete_range_done差距太大
【 TiDB 使用环境】线上
【 TiDB 版本】 5.0.6
【遇到的问题】
【复现路径】做过哪些操作出现的问题
【问题现象及影响】
【附件】
请提供各个组件的 version 信息，如 cdc/tikv，可通过执行 cdc version/tikv-server --version 获取。
【附件】
是做个大量变更吗？试一试如下这个参数
可以设置并行GC，加快对空间的回收速度，默认并发为1，最大可调整为tikv实例数量的50%。可以使用如下命令修改：
update mysql.tidb set variable_values=”3” where variable_name=’tikv_gc_concurrency”
看没有这个variable_name呢，系统有大量的truncate操作。
只有tikv_gc_auto_concurrency这个
你在 mysql.tidb 中查看 tikv_gc_auto_concurrency 参数的说明是： 如果tikv_gc_auto_concurrency 设置为false 的话才启用 tikv_gc_concurrency ，tikv_gc_concurrency 的值 串行或并行 就看你怎么设置了，
但是我在 官档中都没找到 tikv_gc_auto_concurrency、tikv_gc_concurrency的解释说明
4.0的版本文档里https://docs.pingcap.com/zh/tidb/v4.0/garbage-collection-configuration#tikv_gc_auto_concurrency
哦哦， 感谢！！！
目前TiKV是17台，还需要改参数么
- 一般建议使用默认的 auto concurrency 就好了
- 这个问题之前有发生过吗？ 是因为此次删除的数据量非常大？是否可以考虑分批次删除数据，从而缓解 gc 的压力？
一直都是5分钟左右的truncate，可能是一直积压下来导致的，现在有什么办法处理么 ~
- 麻烦上传 tidb-server owner 节点的 tidb.log 包含告警的日志信息
- 麻烦上传 tikv-detail 监控信息
看了下日志感觉和这个问题一样。可以参考下
这个在官档上找不到 相关的信息， 看看是否可以找到源码 ，看看什么情况时抛出这个信息