表统计信息更新导致TiDB节点OOM重启

Bug 反馈
清晰准确地描述您发现的问题,提供任何可能复现问题的步骤有助于研发同学及时处理问题
TiDB所有节点会在凌晨2点全部OOM重启。设置了统计信息在凌晨收集。
| tidb_auto_analyze_end_time | 05:00 +0800 |
| tidb_auto_analyze_ratio | 0.2 |
| tidb_auto_analyze_start_time | 01:00 +0800 |
【 Bug 的影响】
每天凌晨2点过所有TiDB节点全部重启,应用链接会断开一次重连。目前该集群是只读应用,影响面可控。
【可能的问题复现步骤】
表结构包含mediumtext 类型,两张表数据量5000W500G逻辑数据大小。
开启统计信息收集TiDB Server就会重启,关闭就没问题。
【看到的非预期行为】
TiDB Server重启导致所有链接重连
【期望看到的行为】
统计信息采集不影响正常使用(不会导致tidb节点OOM)
【相关组件及具体版本】
v5.1.1
【其他背景信息或者截图】
如集群拓扑,系统和内核版本,应用 app 信息等;如果问题跟 SQL 有关,请提供 SQL 语句和相关表的 Schema 信息;如果节点日志存在关键报错,请提供相关节点的日志内容或文件;如果一些业务敏感信息不便提供,请留下联系方式,我们与您私下沟通。

tidb server凌晨日志
tidb.log-2021-10-03.7z (658.5 KB)

1 个赞

在 v5.1.* 和 v5.2.* 中有一个已知的 analyze 导致 OOM 问题的 bug ,麻烦按照下面这种方式调整下集群:

  • 设置全局变量 tidb_analyze_version 为 1
    • set @@global.tidb_analyze_version = 1;
  • 使用如下的 SQL 生成 DROP STATS 的语句并执行。
    • select distinct(concat(‘DROP STATS ‘,table_schema, ‘.’, table_name,’;’)) from information_schema.tables, mysql.stats_histograms where stats_ver = 2 and table_id = tidb_table_id ;
  • 等待 auto-analyze 重新收集
3 个赞

已经修改回V1 的版本统计信息,我们再观察观察。

第二步记得在业务低峰期也执行下,因为当一个表已经收集到了 version=2 的统计信息时,不管当前变量 tidb_analyze_version 的值是多少,它的 auto analyze 都会收集 version=2 的统计信息,所以需要删除掉原先保留的统计信息。

1 个赞

好的,稍后都执行下

1 个赞

这个bug在新的版本fix了么,目前我们所有集群都把tidb_analyze_version 改回1了。

请问你们统计信息修改成V1版本后,tidb节点OOM的问题解决了吗?

嗯,解决了。这个统计信息版本V2有很多非预期的问题。
修改整v1后不再因为收集统计信息而导致tidb节点OOM了。

1 个赞

这个问题,应该在 v5.3.0 fix 了,5.1 和 5.2 版本的暂时没有 merge,更多的信息见下面的链接:

https://github.com/pingcap/tidb/pull/28729

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