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

Yifei_Jia · 2021 年10 月 3 日 03:51

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)

这道题我不会 · 2021 年10 月 8 日 02:32

在 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 重新收集

Yifei_Jia · 2021 年10 月 8 日 03:20

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

这道题我不会 · 2021 年10 月 8 日 03:22

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

Yifei_Jia · 2021 年10 月 8 日 03:24

好的，稍后都执行下

Yifei_Jia · 2021 年12 月 21 日 01:46

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

AeolusX · 2021 年12 月 24 日 01:29

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

Yifei_Jia · 2021 年12 月 24 日 01:47

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

zhenjiaogao · 2021 年12 月 24 日 03:11

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

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

system · 2022 年10 月 31 日 19:16

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