tidb server 异常OOM

Lawrence · 2021 年9 月 23 日 03:42

tidb: 5.0.3

一个sql，看执行计划，下推到了tiflash，只获取 limit 10条，tidb server 竟然OOM了

SELECT main_post_id ,COUNT(1) FROM kol_doc kd
GROUP BY main_post_id HAVING COUNT(1) > 1 LIMIT 10

tidb 日志：tidb.tar.gz (7.1 MB)

xfworld · 2021 年9 月 23 日 03:57

tidb 给了多少内存？

Lawrence · 2021 年9 月 23 日 03:59

16个G，可用14.9G，而且这个执行计划显示应该只推给tidb 10条数据。。

xfworld · 2021 年9 月 23 日 05:55

tiflash 给的内存够么？看哪个分析 OOM 的结果，貌似是 tiflash 内存不足

Lawrence · 2021 年9 月 23 日 06:07

tiflash是3台，每台可用内存30.3G，看监控当时确实是tiflash用了大量内存，然后紧接着tidb server内存也打满了但是看执行计划tidb server 是不应该被打满的，就 load 10条记录，而且tiflash没到用完OOM的地步，tiflash也没有重启，另外即使是tiflash内存不够了，为什么是tidb server oom了呢

xfworld · 2021 年9 月 23 日 06:23

tidb OOM 的场景太多了，你那边有更多的日志可以提供么？ ( tiflash 和 tidb ，瞬时OOM 前后的日志 )

Lawrence · 2021 年9 月 23 日 06:26

11点31，就是我执行的这个sql引起的OOM，无其他人在使用，而且你看这个图爆出的OOM的sql 也是tidb 输出的日志，就是这个SQL引起的

tidb日志中的一条oom记录：
[memory_usage_alarm.go:141] [“tidb-server has the risk of OOM. Running SQLs and heap profile will be recorded in record path”] [“is server-memory-quota set”=true] [server-memory-quota=8000000000] [“tidb-server memory usage”=6494551152] [memory-usage-alarm-ratio=0.8] [“record path”=“/tmp/1001_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage/record”]

spc_monkey · 2021 年9 月 23 日 07:34

这个SQL 肯定有问题，我先看看有没有 hint 能解决，不过你上面提供的是 explain 的结果，能提供一下 explain analyze 的结果不

spc_monkey · 2021 年9 月 23 日 07:35

慢日志有个 tidb_plan 的字段，可以提供这个（名字不是很确定）

Lawrence · 2021 年9 月 23 日 07:39

这个sql都能有问题吗。。。 explain analyze 拿不到，一执行tidb server直接重启了，dashboard上也找不到这个sql记录，我都是从日志里找出来的，慢日志里也没有，因为这个sql就没成功执行下来，tidb server就挂机了

spc_monkey · 2021 年9 月 23 日 07:40

这个 SQL 只占用 1.xG 内存，这是异常的，但只有一个 SQL 执行就 oom ，还有其他问题

Lawrence · 2021 年9 月 23 日 07:42

你是说这个sql只用了1G内存，然后OOM了，可能存在其他问题？，但是有个疑问就是，执行计划显示只会给tidb server 推10条记录，需要用tidb 1G内存?

这个是建表语句、sql、和explain
建表语句和explain.txt (2.9 KB)

spc_monkey · 2021 年9 月 23 日 07:44

1、你得出这个 SQL 的途径，是啥？我这边建议你看慢日志（或者看 tidb- server 的日志），你的这个 SQL 如果是上面的执行计划，连 1M 的内存都占用不了，不会造成 OOM

spc_monkey · 2021 年9 月 23 日 07:46

2、你上面分析的最大内存是 1.xG 的内存，但我看这个分析的结果，应该是根据慢日志分析出来的对吧，我建议你确认一下，当时这个 1.xG 内存的 SQL，是不是这个 SQL 而且当时的执行计划是啥，慢日志里有，建议提供一下

spc_monkey · 2021 年9 月 23 日 07:47

这个得看具体的慢日志内容，你上面的分析途径，我还需要确认

Lawrence · 2021 年9 月 23 日 07:59

1.得出这个结论的途径是：我们tidb server挂了，我去看了该server 日志，发现：tidb 触发一个oom，并记录在了/tmp/1001_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage/record下，然后日志下面就显示tidb 重启了

我去看了下这个文件，显示的该sql：

spc_monkey · 2021 年9 月 23 日 08:03

嗯嗯，明白了，但这里的问题是：这个文件中记录的这个SQL使用了 1.66GB 的内存，但你的执行计划估计才几K，差距太大，所以想看看这个 SQL 真正的执行计划才行（explian analyze。会记录使用了多少内存）

Lawrence · 2021 年9 月 23 日 08:04

但是explain analyze的话，tidb 直接就挂了，出不来这个结果，怎么拿到呢

spc_monkey · 2021 年9 月 23 日 08:11

1、可以看一下慢日志，找一下是否有这个 SQL
2、确认 tidb-server 是否可以开 oom-use-tmp-storage 之类的参数（关于 oom 和内存控制，tidb-server 都有对应的好几个参数）

Lawrence · 2021 年9 月 23 日 08:17

1.看了下慢日志，没有该sql，应该是因为根本没执行下来，也没记录，在dashboard上也没有该记录
2.这个参数本身就是开启的

3.所以这个应该可能是个潜在的问题吧，执行计划是对的，而且可能应该只用几KB，但实际日志显示1G，还OOM，感觉很奇怪
4.如果可以，我可以teamviewr共享屏幕操作一波，直接看效果