GC life time is shorter than transaction duration ，GC时长短于表分析时长

🪐 TiDB 技术问题 部署&运维管理
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】V6.1.2
【复现路径】
【遇到的问题：问题现象及影响】
日志里面有错误信息

r\": null\n}"]
[2023/01/12 11:34:32.551 +08:00] [ERROR] [update.go:1218] ["[stats] auto analyze failed"] [sql="analyze table `remote_vehicle_prod`.`history_wti_alarm` partition `p1`, `p2`, `p3`, `p4`, `p5`, `p6`, `p7`, `p8`, `p9`, `p10`, `p11`, `p12`, `p13`, `p14`, `p15`, `p16`, `p17`, `p18`, `p19`, `p20`, `p21`, `p22`, `p23`, `p24`, `p25`, `p26`, `p27`, `p28`, `p29`, `p30`, `p31`, `p32`, `p33`, `p34`, `p35`, `p36`, `p37`, `p38`, `p39`, `p40`, `p41`, `p42`, `p43`, `p44`, `p45`, `p46`, `p47`, `p48`, `p49`, `p50`"] [cost_time=20m3.380803402s] [error="[tikv:9006]GC life time is shorter than transaction duration, transaction starts at 2023-01-12 11:14:29.123 +0800 CST, GC safe point is 2023-01-12 11:22:09.173 +0800 CST"]

【资源配置】
【附件：截图/日志/监控】

image
image2870×942 428 KB

2

调高 gc 时间呢

3
  1. 如果是超级大表，可以定期手动 analyze；
  2. 可以尝试开启tidb_enable_fast_analyze；
  3. 可以适当调高gc时间；
4

建议大表部署手工任务（非业务时间，小样本收集，多线程）收集，不然你gc调的再长，只要表够大，都会超时的。。。

5

tidb_enable_fast_analyze 或者关闭自动analyze 用手工。
对单个分区会快很多
analyze table t partition p1;

自动更新

在发生增加，删除以及修改语句时，TiDB 会自动更新表的总行数以及修改的行数。

系统变量名 默认值 功能
tidb_auto_analyze_ratio 0.5 自动更新阈值
tidb_auto_analyze_start_time 00:00 +0000 一天中能够进行自动更新的开始时间
tidb_auto_analyze_end_time 00:59 +0000 一天中能够进行自动更新的结束时间
1 个赞
6
tidb_auto_analyze_ratio 0.0 自动更新阈值
tidb_auto_analyze_start_time 00:00 +0000 一天中能够进行自动更新的开始时间
tidb_auto_analyze_end_time 08:59 +0000 一天中能够进行自动更新的结束时间
一般表统计放在网上没人的时候比如夜里0点到8点钟。白天不更新
1 个赞
8

6.1种不是对analyze和gc 做了优化, gc时间随着analyze调整，而且analyze有个max time?

9

image
可以期待一下6.5引入的这个参数的真正生效吧。现在analyze分区表，都是按照分区逐个来搞的，默认的10min很容易超过。其实还是建议调大一下tidb_gc_life_time时间，我现在是设置的6个小时，如果真的业务做了啥傻事，还有回转的空间。目前来看，对查询效率影响不大

1 个赞
10

PS：如果你用了动态分区裁剪功能，要注意提醒下业务是否遇到了这种BUG。

11

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。