几套集群gc不推进，集群压力大

Leonard · 2026 年6 月 23 日 04:45

一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题

【TiDB 使用环境】生产环境
【TiDB 版本】v7.5.5
【部署方式】物理机
【操作系统/CPU 架构/芯片详情】

【机器部署详情】CPU大小/内存大小/磁盘大小

【集群数据量】
78T
【集群节点数】
36 tikv 5 tidb 5 pd
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】

gc 不推进，tikv cpu 上升，集群压力上升，sql执行变慢

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

tikv cpu

tidb 延迟

Leonard · 2026 年6 月 23 日 05:09

没有开ticdc，日志增量备份已经暂停。尝试过重启所有tikv，tidb以及transfer pd leader 都没有什么作用

克里克里克 · 2026 年6 月 23 日 05:23

» service-gc-safepoint
看看是什么。
参考下。
博客 - gc不能正常消除版本 | TiDB 社区

Leonard · 2026 年6 月 23 日 05:25

service-gc-safepoint
{
“service_gc_safe_points”: [
{
“service_id”: “1760368080898754003_pause_safepoint”,
“expired_at”: 1782276493,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-11765258”,
“expired_at”: 1782197232,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-11765259”,
“expired_at”: 1782197207,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-11765260”,
“expired_at”: 1782197213,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-11765261”,
“expired_at”: 1782197242,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-11765262”,
“expired_at”: 1782197222,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-11765263”,
“expired_at”: 1782197244,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1220852530”,
“expired_at”: 1782197289,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1220852531”,
“expired_at”: 1782197282,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1220852532”,
“expired_at”: 1782197152,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1220852533”,
“expired_at”: 1782197253,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1220852534”,
“expired_at”: 1782197267,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1220852535”,
“expired_at”: 1782197148,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1558018212”,
“expired_at”: 1782197196,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1558018213”,
“expired_at”: 1782197275,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1558018214”,
“expired_at”: 1782197201,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1558018215”,
“expired_at”: 1782197283,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1558018216”,
“expired_at”: 1782197205,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-1558018217”,
“expired_at”: 1782197147,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-289782690”,
“expired_at”: 1782197237,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-289782691”,
“expired_at”: 1782197247,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-289782692”,
“expired_at”: 1782197215,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-289782693”,
“expired_at”: 1782197206,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-289782694”,
“expired_at”: 1782197198,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-289782695”,
“expired_at”: 1782197222,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-563652110”,
“expired_at”: 1782197150,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-563652111”,
“expired_at”: 1782197283,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-563652112”,
“expired_at”: 1782197257,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-563652113”,
“expired_at”: 1782197249,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-563652114”,
“expired_at”: 1782197290,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-563652115”,
“expired_at”: 1782197286,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-894152193”,
“expired_at”: 1782197264,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-894152194”,
“expired_at”: 1782197277,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-894152195”,
“expired_at”: 1782197158,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-894152196”,
“expired_at”: 1782197258,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-894152197”,
“expired_at”: 1782197250,
“safe_point”: 467189088465453145
},
{
“service_id”: “backup-stream-1760368080898754003-894152198”,
“expired_at”: 1782197256,
“safe_point”: 467189088465453145
},
{
“service_id”: “gc_worker”,
“expired_at”: 9223372036854775807,
“safe_point”: 467188183557472256
},
{
“service_id”: “log-backup-coordinator”,
“expired_at”: 1782276487,
“safe_point”: 467189088465453145
}
],
“gc_safe_point”: 467185774087110656
}

Qiuchi · 2026 年6 月 23 日 05:35

有未完成的查询么，另外 db 节点日志里面 grep 下 gc_worker， tidb_gc_max_wait_time 设置的多少，另外截下 tikv grafana thread cpu

Leonard · 2026 年6 月 23 日 05:51

tidb_gc_max_wait_time 设置600了

克里克里克 · 2026 年6 月 23 日 05:59

看着不是日志阻塞的。gc的速度跟不上。
参考下：GC in Compaction Filter 机制
GC 配置 | TiDB 社区版

Leonard · 2026 年6 月 23 日 06:08

看起来都是一样的

Leonard · 2026 年6 月 23 日 06:20

compaction相关的监控，时间上也吻合

克里克里克 · 2026 年6 月 23 日 06:25

排查下这段时间是不是一直触发流控了？导致gc处理慢，而且14:00之后gc speed速度还上不去么

Leonard · 2026 年6 月 23 日 06:27

是的，safepoint 就不推进。gc流控没改过，是默认值

Leonard · 2026 年6 月 23 日 06:38

克里克里克 · 2026 年6 月 23 日 06:39

TiKV-Details下的Thread CPU和Flow Control和Scheduler这三个标签的监控发一下看看。
gc是有调度的，就是处理不过来。

TiDBer_yyy · 2026 年6 月 23 日 06:42

看看是不是这个问题

另外看日志备份怎么搞的，是不是有阻塞，我历史遇到ticdc相关问题，也导致cdc不推进，可以参考一下思路：记录故障处理：v7.1.0 版本gc不能正常推进

Leonard · 2026 年6 月 23 日 08:12

没开ticdc。日志备份状态看是正常的

wbslxw · 2026 年6 月 23 日 10:21

优化慢存储：更换 IO 性能更好磁盘，分离冷热数据，降低 Slow Stores 数量；

Leonard · 2026 年6 月 23 日 11:47

磁盘已经都是nvme的了

Raymond · 2026 年6 月 23 日 15:43

你是gc不推进还是compaction 有问题啊
gc 设置为多久，看下最后的gc safe point是几点
我之前遇到了一个gc 不推进，解决了，可以分享下我的经验

TiDBer_aaaaa · 2026 年6 月 24 日 01:14

你先拉取 CDC 监控看下延迟曲线，核对 sorter 内存，调高并发测试，排查上下游写入瓶颈。

随缘天空 · 2026 年6 月 24 日 01:29

该时间段内有没有大事务？如果事务执行时间过长会导致gc暂时不推进，等待事务结束才能推进。可以在dashboard的日志搜索菜单中搜索集群压力大开始的时间段内搜索下日志，日志类型选择error，关键词“ttl manager”试试，找到对应的sql语句