TiDB OOM导致重启

[TiDBer_qqabzOs3]

【 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的含义是什么，什么情况下会发生，怎么避免该问题

[hey-hoho]

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

[buddyyuan]

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

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

[tidb菜鸟一只 (小菜一颗)]

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

[TiDBer_qqabzOs3]

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

[TiDBer_qqabzOs3]

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

[TiDBer_qqabzOs3]

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

[Aric (Jansu Dev)]

@buddyyuan

heap

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