多台TIDBServer(5.1.4) 相近的时间内存上升，服务重启

[huixiang]

【 TiDB 使用环境】生产环境
【 TiDB 版本】5.1.4
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
1. 线上的TIDB Server集群，3个节点在相近的时间点，内存使用突增并发生重启。
2. dmesg -T | grep tidb-server 这个没有看到系统相关的OOM KILL 信息。 在TIDB中的errorlog中有 fatal error: runtime: out of memory 信息。
3. 问：
3.1）问下这个OOM的阀值是和哪个参数有关？是否是有Default，是多少呢？
3.2） Dashboard中SQL首次出现，及最大内存的含义？

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
1. 线上的TIDB Server集群，3个节点在相近的时间点，内存使用突增并发生重启。
2. TIDBServer配置 128G内存。

![image|690x179](upload://4NRW3C6BlqOmPHPu6m7i87jboTO.png)

    3. dmesg -T | grep tidb-server 没有发现OOM相关内容。
     4. tidb日志上记录到重启

     5. 错误日志有runtime: out of memory

cat tidb_stderr.log |grep error -i -A 3 -B 3
fatal error: runtime: out of memory

    6. dashboard大SQL记录。

[huixiang]

3.1）问下这个OOM的阀值是和哪个参数有关？是否是有Default，是多少呢？
3.2） Dashboard中SQL首次出现时间及最大内存的含义？
首次出现时间是server重启就会重新开始计算吧？

[小龙虾爱大龙虾 (Minghao Ren)]

1. runtime OOM了，应该是真的向操作系统申请不到内存了
   2.Dashboard 中的 SQL 语句分析，后台表是 statement_summary 系列表，都是存储在内存的，并且按 sql_digest 分组的，tidb server 重启是会丢失的，首次出现在时间，就是第一次执行的时间，最大内存就是单次执行的最大内存，50 G肯定是有问题的，把执行计划发出来看看

[WalterWj (王军 - PingCAP)]

关于问题 1，
OOM 是系统行为，这个和 tidb 无关。您这个问题比较奇怪的是 tidb 重启了 系统日志没有 OOM 记录。就是服务器内存使用过多，会杀掉内存使用最多的那个进程。也就是 tidb-server

关于问题 2，
是说 你这个 sql 跑了 n 次，平均 tidb-server 内存使用是 106mb，最大内存使用是 50GB。应该和你数据分布和 sql 条件有关系。要么当时 sql 执行计划有点问题。找找这个sql 的慢日志有没有记录呢。

[huixiang]

SQL:
SELECT a.category_id AS categoryId, categoryReplyCount, b.rTopicId AS topicId, b.replyId AS replyId, b.rContent AS content, b.rContentStruc AS contentStruc, b.rReplyDate AS replyDate, b.rLastEditDate AS lastEditDate, b.rMemberId AS memberId, b.rMemberName AS memberName, b.rProvinceName AS provinceName FROM ( SELECT A.category_id, A.reply_id, A.is_hq, (SELECT COUNT(*) FROM CategoryReplyRelation WHERE A.category_id=category_id GROUP BY category_id) AS categoryReplyCount FROM CategoryReplyRelation AS A WHERE A.category_id IN ( ? , ? , ? , ? , ? , ? , ? , ? , ? ) AND A.id = (SELECT id FROM CategoryReplyRelation WHERE category_id=A.category_id ORDER BY category_id, is_hq DESC, reply_id DESC LIMIT 1)) a JOIN ClubReply b ON reply_id = b.replyId WHERE rDelete = 0 ORDER BY category_id [arguments: (47372, 47371, 47370, 47369, 47368, 47367, 47366, 47365, 47364)];

[呢莫不爱吃鱼]

有点奇怪，我试了下如果tidb server因为oom 重启过，那么dmesg -T | grep tidb-server 中应该是有相应记录的。

[WalterWj (王军 - PingCAP)]

@huixiang

SELECT a.category_id AS categoryId, categoryReplyCount, b.rTopicId AS topicId, b.replyId AS replyId, b.rContent AS content, b.rContentStruc AS contentStruc, b.rReplyDate AS replyDate, b.rLastEditDate AS lastEditDate, b.rMemberId AS memberId, b.rMemberName AS memberName, b.rProvinceName AS provinceName FROM ( SELECT A.category_id, A.reply_id, A.is_hq, (SELECT COUNT(*) FROM CategoryReplyRelation WHERE A.category_id=category_id GROUP BY category_id) AS categoryReplyCount FROM CategoryReplyRelation AS A WHERE A.category_id IN ( ? , ? , ? , ? , ? , ? , ? , ? , ? ) AND A.id = (SELECT id FROM CategoryReplyRelation WHERE category_id=A.category_id ORDER BY category_id, is_hq DESC, reply_id DESC LIMIT 1)) a JOIN ClubReply b ON reply_id = b.replyId WHERE rDelete = 0 ORDER BY category_id [arguments: (47372, 47371, 47370, 47369, 47368, 47367, 47366, 47365, 47364)];

你这 SQL 截图看是已经落盘了都。
有试过用这个 argument 手动执行下看看数据分布么？
或者执行计划贴个文本上来看看呐。

[小龙虾爱大龙虾 (Minghao Ren)]

看执行计划里统计信息都是假的

[huixiang]

今天和TIDB老师再次分析，给出的问题原因是 SQL的执行计划变化了。

1. 平时是indexjoin
   

   

2. 故障时是hashjoin
   

   

数据表大小:
clubreply 14.4亿(16.8G) , CategoryReplyRelation 11W

[迷途小书童]

升级版本试试