6.5 tidb server oom 重启的问题

【 TiDB 使用环境】测试
【 TiDB 版本】v6.5.0
【复现路径】执行高内存占用的查询
【遇到的问题:问题现象及影响】
tidb服务器8c32g,集群tidb|pd三台,tikv六台
tidb_server_memory_limit = 80%
tidb_mem_quota_query = 21474836480 (20g)

查询时tidb server日志如图,出现 “global memory controller failed to kill the top-consumer in 10s”

running_sql 中出现了两个完全一样的 sql 条目 ,sql text、统计信息等完全一样,mem_max 均为15 GB,和超过服务器物理内存,但是一个是 sql 0 一个是 sql 4,这个日志被覆盖了传不了了,可以参照这个的sql 0 和 sql1
running_sql (16.2 KB)

请问6.5版本的全局内存限制是否可以完全杜绝因oom导致的tidb server重启的问题?failed to kill 的问题该如何解决?

1 个赞

6.5不能杜绝oom导致的tidb-server重启,但是很大程度上减少了内存的使用(paging能力)以及对消耗内存高的SQL的global kill能力。但是需要注意的是:
1、当内存使用比较高的情况下,每次只会杀掉占用内存最多的一个SQL,每分钟一次,如果内存上涨比较快,且多个占用内存高的SQL同时跑,那么也有可能会导致OOM的情况。
2、如果系统内部发出了kill命令,但是响应不及时那么也会继续占用内存,导致实例oom,你这种场景可能遇到的就是kill不及时,在进入hashagg算子时候有一些场景目前测试是kill没那么及时。
你这里内存占用比较大应该是hashagg算子导致的,group by:dcdb.cr_trans_remain_mapping.ta_cfm_serial_no这里目测这个字段的重复度比较低导致大量内存中的分组聚合,需要进行规避:1、想办法不走hashagg,比如看是否能用streaagg代替;2、不采用默认的并发方式,给hashagg聚合算子设置单线程set global tidb_hashagg_final_concurrency=1;set global tidb_hashagg_partial_concurrency=1,同时开启落盘;但是要注意的是tidb目前的落盘处理性能比较差,参考这里:https://asktug.com/t/topic/994873,官方后续应该会对落盘进行优化。

你这里看cr_trans_remain_mapping.ta_cfm_serial_no这个字段是否有索引,如果没有可以尝试加一个,让其尽量走streamagg算子。

3 个赞

大体了解了,感谢

这里说错了,是 tidb_server_memory_limit_gc_trigger一分钟执行一次。 kill是每次执行完判断内存不足后继续kill。

1 个赞

想到个别的问题再请教下,就是通过设置tidb_executor_concurrency来限制hashagg的并发度时,若不考虑落盘功能的影响,同一个sql整体跑下来所需要的内存会比以前更少么?还是说只是相较之前内存增长的速度变缓了,执行的速度也变缓了,但最终占用的内存和之前一样?

这个参数是几乎控制所有算子的并发度的,如果只限制hashagg就按照我上面给的那两个参数设置。
并发越多是不是内存用的越多,这个很难讲,比如你聚合字段是性别,那么并发越多内存越多,但是整体用的内存很少啊。如果你聚合字段数据重复度很低,那么没准非并发情况下的一个hashtable结构比并发情况下的多个hashtable结构需要的数据更多呢。我猜测并发越多普遍来说应该会多那么一点点吧,可以自己测试下看看。

1 个赞

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