3节点tikv中1个节点GC慢

[h5n1]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【概述】：场景 + 问题概述

【背景】：做过哪些操作

【现象】：业务和数据库现象

【问题】：使用kafka进行数据消费同步，tidb集群中3个tikv节点，每节点4块SAS盘，其中67.80节点IO利用率高，GC时间长。监控见附件

【业务影响】：

【TiDB 版本】：4.0.13

【附件】：
grafana.rar (3.8 MB)
pd-ctl store|grep -E ‘id|address’
“id”: 4,
“address”: “10.161.67.80:20160”,
“status_address”: “10.161.67.80:20180”,
“id”: 5,
“address”: “10.161.67.85:20160”,
“status_address”: “10.161.67.85:20180”,
“id”: 1,
“address”: “10.161.67.84:20160”,
“status_address”: “10.161.67.84:20180”,

[yilong (yi888long)]

1. 更换 ssd 磁盘
2. 建议可以先升级到 v5.0.x 版本 , 5.0 默认开启 GC in Compaction filter 功能，减少 GC 对 CPU、I/O 资源的占用

[h5n1]

已升级5.0.2，GC in compaction filter已生效，有如下2个问题：

1. 升级前region数量为78401 ，启动之后region health显示有78345个empty-region 然后一直进行合并。之后region数量达到71783个，为什么系统启动后会认为有78345个empty-region? 最后合并减少6000多个region 这些region是 否是因为GC新特性快速删除过期数据后产生的？(近期没有truncate drop等操作)
   
   
   
2. 14:59分GC完成resovlelocks阶段。15:17分开始compaction filter GC 。 按照GC流程 1. resovle lock 2. delete range 3. do GC 3个阶段的话，在没有drop truncate操作情况下 阶段1结束到阶段3开始中间有16分钟，
   14:59 15:59 2次GC操作都是 Compaction GC时间比resolve lock晚16分钟左右，为什么中间会有这么长时间的间隔？ compaction GC是如何触发调用的，引入该功能后是否还遵循以前版本的 3阶段处理方式？
   
   
   
   
   
   
   
   
   
   
   

[yilong (yi888long)]

1. 有可能，可以观察下是否还有这种变化
2. 麻烦找一个日志，挑一段时间看下。
3. show config where type = ‘tikv’ and name like ‘%enable-compaction-filter%’; 看下配置