【 TiDB 使用环境】生产环境
【 TiDB 版本】
【遇到的问题：问题现象及影响】
tidb集群触发TiKV pending task too much 告警，当前集群的gc.enable-compaction-filter=true
正常业务场景中存在大量update和delete
【期望解决的问题】
当前版本下，应该如何调优来解决TiKV pending task too much的问题？
【监控截图】
根据监控指标发现是gc_worker非常高，且gc worker cpu打满100%，gc 耗时变长
找慢sql
注意
在使用 Compaction Filter 机制时，可能会出现 GC 进度延迟的情况，从而影响 TiKV 扫描性能。当你的负载中含有大量 coprocessor 请求，并且在 TiKV-Details > Coprocessor Detail 面板中发现 Total Ops Details 的
next()或prev()调用次数远远超过processed_keys调用的三倍时，可以采取以下措施：
- 对于 TiDB v7.1.3 之前版本，建议尝试关闭 Compaction Filter，以加快 GC 速度。
- 从 v7.1.3 开始，TiDB 会根据每个 Region 的冗余版本数量
region-compact-min-redundant-rows和比例region-compact-redundant-rows-percent自动触发 compaction，从而提高 Compaction Filter 的 GC 速度。因此，在 v7.1.3 及之后的版本中，如果遇到上述情况，建议调整这两个参数，无需关闭 Compaction Filter。
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-configuration#gc-in-compaction-filter-机制
这个机制下面有个注意，你看看是不是就是这种情况？
感觉还好吧，说名那个时间需要GC的多，并不是一直的持续高， gc safepoint前做过较大量的update、delete吗。
慢sql会影响gc_worker的数量吗？
Total Ops Details 的 next() 或 prev() 调用次数远远超过 processed_keys 调用的三倍，我对比了这两个指标，比例大概是1.8，还没到3倍
是的，存在批量update和delete的情况
关闭这个filter后，使用的是单独gc线程，据说对性能影响较大 
我认为这是正常的，把告警值调大就眼不见心不烦了。
大事务造成的正常现象，等他gc完就没事儿了~
如果长时间持续报警，那就得关注了
既然不属于这个情况，我也觉得其实没啥。
从耗时上看，最大也就是1s。
