TiDB OOM导致重启

【 TiDB 使用环境】
生产环境
【 TiDB 版本】
v6.4.0
【遇到的问题:
TiDB突发内存陡增,触发OOM事件,经查慢日志,定位为执行了内部SQL导致,SQL内容如下:
SELECT
HIGH_PRIORITY table_id,
is_index,
hist_id,
distinct_count,
version,
null_count,
cm_sketch,
tot_col_size,
stats_ver,
correlation,
flag,
last_analyze_pos
FROM
mysql.stats_histograms;

这个SQL的含义是什么,什么情况下会发生,怎么避免该问题

这个是查表的直方图信息,和统计信息有关的。这个SQL执行频率不会太高,内存使用量不大,应该不是造成OOM的原因,再找找其他SQL吧。

2 Likes

一般都设置了 memory-usage-alarm-ratio 的,超过这个阈值,就会将内存中的 goroutinueheaprunning_sql dump到文件。可以检查下这些文件,看看究竟是什么原因导致的。

https://docs.pingcap.com/zh/tidb/stable/configure-memory-usage#tidb-server-内存占用过高时的报警

不应该是这个sql导致的,这个sql就是收集统计信息用的,建议再排查下其他sql

但是从慢查中查询,对比OOM时间,只有这条语句是吻合的,除了这个SQL消耗内存是百MB,其它的SQL都是KB

这个是部署在K8S上的,TiDB是无状态,重启后日志已经不见了

但从慢查中查找,只有该SQL占用内存最高,近300MB,而其它SQL最大的也才不到50MB,并且从OOM时间上也只有该SQL吻合

buddyyuan 老师所说,还是要看下 heap 和 log 的行为跟这条 SQL 的掉用又称是否吻合,现在支持猜测 OOM 与这条 SQL 有关,但无法证明。